The question: Should I use .Net Core Identity or IdentityServer 4 with Identity
I need to build app with login/register functionality and allow users to use APIs to import/export data from my software. I also want to have external logins like google, twitter, etc.
And I'm not able to understand why would I need Identity Server when all things can be done using only Identity.
Why would I need or want IdentityServer ? I just need to get work done right and as simple as possible.
You really can't compare the two.
ASP.NET Identity is a database API to manage users, roles, claims, email confirmation tokens etc. Something you can use for implementing signup, login, change password etc.
IdentityServer is an OpenID Connect and OAuth 2.0 implementation. It gives you features like single sign-on and API access control. This is useful if you want to share users between multiple client applications.
You can combine both though - use IdentityServer for the protocol work, and ASP.NET Identity for the user management on your central login page.
It depends.
IdentityServer will provide you with OAuth 2.0 and OpenID Connect implementation, and it will handle all details for you (providing you endpoints, token management, scopes, grants and so on). It runs independently so you can use it for multiple clients (SPA, mobile, web apps) and it is nicely isolated from rest of your app. If you wish so, you can use it together with ASP.NET Core Identity.
If you don't use IdentityServer, you will have to write some of these things yourself because ASP.NET Core Identity is a membership system and it does not provide any ready to use endpoints and neither token management or support for different ways how to authorize.
You need to evaluate whether it is better for you to write these things yourself but have a more straightforward setup because you probably don't need everything IdentityServer provides although it might limit you in future.
You can also have a look at OpenIddict that is less complicated than IdentityServer.
Related
I got absolutely confused when trying to understand the differences between MicrosoftAccount, AzureAD and OpenIDConnect authentications.
I am trying to build a .Net Core MVC app that allows some users to authenticate with local accounts, but some with Microsoft accounts. I do need to have a local user in DB for both types of authentications as I have some custom authorization mechanisms built on that.
I started with creating the app from template and selected "local accounts" authentication. Then I added the MicrosoftAccount authentication according to this tutorial (https://learn.microsoft.com/en-us/aspnet/core/security/authentication/social/microsoft-logins?view=aspnetcore-3.1). This is using Microsoft.AspNetCore.Authentication.MicrosoftAccount and seems to be working fine.
However, when I create a new app from template and select "work or school account" authentication I can see it uses a different library - Microsoft.AspNetCore.Authentication.AzureAD.UI. It seems to do the same thing. I can see there are events I could hook into to connect the AAD user with my local DB.
Looking through the web I found some other tutorials that were using OpenIDConnect for the same purpose.
How are those methods different? Which one should I use and why?
In future I would like to be able to query the user's directory for a list of other users. Would that requirement be easier met with either of those three methods?
MicrosoftAccount: This is the login with a general Microsoft account, using OAuth2. This is also what Microsoft will refer to as “private account” and useful when you want to authenticate someone just using their Microsoft login as an external authentication provider. This is similar to how you would sign in to sites with your Google account.
AzureAD: This is the sign in to a specific Azure tenant. This is often understood as a “work or school account” because it doesn’t sign people in using a public account but rather some account bound to some organization. Usually, you would have an Azure tenant where you have direct users (or configure it to allow external users) but you want to control access through that Azure AD.
OpenIdConnect: This is the general OpenID Connect protocol which you can use to sign in with many different authentication providers because it is a protocol that many of them will support. You can use OIDC to sign in to either of the above (and many other services) but that will require you to do some more configuration as you will need to figure out specific addresses for example.
You can always use the OpenIdConnect or the OAuth authentication scheme to authenticate with most authentication providers but those are the “manual” schemes which will require you to configure additional things. All the other authentication schemes, including MicrosoftAccount and AzureAD but also the other ones like Google or Twitter build on top of those protocols and come preconfigured so that you do not need to set up much else. So those are mostly for convenience and for more specialized support.
So when you want to authentication through Microsoft or Azure, then you should choose MicrosoftAccount or AzureAD. Which of those depends on where you want to authenticate with. If you have an Azure AD, then you should use that.
I have a working implementation of IdentityServer4 with custom user stores, etc.
I have an asp.net core web app that I want to require user login for certain pages through the IdentityServer4 instance with my site having full ASP.Net Core Identity functionality e.g. my razor pages accessing User etc.
I have been searching for 3 days and while the internet seems to have lots of resources available on very similar topics, they all do things a little differently. I feel like I just don't know the right keywords to search for.
I have been following many online tutorials such as JWT Authentication on .Net Core and all of the quickstarts on identityserver4.io but they all leave out crucial steps.
IdentityServer is an implementation of oidc, which means that it serves as an independent, central authentication point. Client apps should be unaware of users credentials. That's part of the responsibility of IdentityServer.
So the reason you won't find answers and you think steps are missing, is because you are not implementing oidc.
It is not possible to 'hide' IdentityServer when a user has to login there.
That leaves you with three options:
implement Resource owner password flow. In that case you can collect the credentials and send it to IdentityServer. Please note that there may be security issues when you use this.
Do not use IdentityServer but instead implement Asp.Net Core Identity.
Send information to IdentityServer to identify the client and use custom presentation for that client. In that case the url may be different but the look and feel remains the same.
I am "learning" about the development of ASP.NET Web APIs with security provided by OAUTH2 and OpenId. So I have started with the Web API Template. The Web API Template has its own "Individual Account" user management mechanism which can issue tokens via /Token. However getting Refresh Tokens with this mechanism is a little trickier.
This got me thinking, should I be really looking to provide this functionality by using IdentityServer instead. If so, as I understand it, as I am using ASP.NET 4.7/MVC5, and not ASP.Core, then I should use IdentityServer3 and not version 4.
Also there is all of the login functionality required when the Access Tokens and Refresh Tokens are expired.
It's unlikely that anyone will be able to definitively tell you whether to use Identity Server or not. You will need to make that decision yourself as you understand the problem domain the most.
If you do decide to offload authentication to a central authority provider (like Identity Server) then I can tell you that there is no hard dependencies that would force you to use Identity Server 3 or 4 as they both ultimately conform to oauth2/oidc protocol. If you have ability to host .Net Core apps then I can recommend you to use Identity Server 4 as that implementation is significantly more extensible and offers extreme flexibility.
I have Angular 2 application which talks to the Web API and does some basic CRUD operations. I have few questions:
Is any way I can create a Login/Register page on Angular 2 using ASP.NET Identity?
How do I manipulate with a data only relates to the logged in user? (Token Based Authentication? How it works? Where to read about it?)
How can I implement login/register process on actual Angular 2 application without redirecting me to Identity Server?
I looked at IdentityServer4, OAuth2 and OpenID examples, it is a bit too complex to understand. I went thru every single step in quick start, it works but I don't understand how and what it does.
Can someone give me any resources where I can start from? Blogs, websites, books, step-by-step guides.
You're correct that at this point the most comprehensive solutions for authentication and authorization in systems that rely heavily on HTTP are based on OAuth 2.0 and OpenID Connect. This of course includes your specific scenario of a SPA calling a Web API back-end. For further read on this generic case you can check the Auth0 SPA + API Architecture Scenario or give a look at the quickstarts focused on your selected technologies:
Angular2 Quickstart
ASP.NET Core Web API Quickstart
Note: Auth0 supports OAuth 2.0/OpenID Connect so even though the docs may have additional features that are provider-specific, you may find them useful if you do indeed decide to go the OAuth 2.0/OpenID Connect route. It's one of the advantage points of relying on standards, it's easier to switch between implementation/providers.
However, you should also consider if you really need to go full OAuth 2.0/OpenID Connect as they aim to solve a lot of different use cases and as such also bring significant complexity with them. If you go that route, it's recommended that you leverage existing libraries like IdentityServer or cloud providers like Auth0, because doing your own implementation carries a lot of risk and requires significant effort.
In order to meet your requirement of providing an integrated login from within your own Angular2 front-end you could probably look into the resource owner password credentials grant specified by OAuth2.
Another alternative is doing your own custom solution, this is generally frowned upon, because it's easy to get wrong, but the theory would be:
Handle user authentication and registration (possibly using ASP .NET Identity)
Upon login exchange user credentials with some a token that you can later use to call into the API
The token could just be a random (not guessable) value used as a reference to some server-side storage that would contain information about the associated user.
I've recently been digging into WIF 4.5 in order to retrofit an older role based Webforms application with finer grained permissions. The application is using Windows Auth, so it appears to be relatively straightforward to implement claims based authorization. I can decorate pages and methods with ClaimsPrincipalPermission identifying the resource and action. And I can plug-in a custom AuthorizationManager to apply the authorization rules. There are plenty of good examples of how to do this. Here are a few:
Leveraging claims based security in asp.net 4.5
Going beyond usernames and roles
Identity and Access Control in WCF 4.5
What I can't seem to find are good examples of how to best manage the users' claims. There are two basic challenges that I see.
How do I keep the application claims in sync with the user claims?
How do I discover or keep track of all of the claims that the app
requires? And how do I then make sure that users have all of the
claims they require and manage this over time?
How do I prevent an explosion fine grained claims that leads to unwieldy claims management and complex authorization rules?
I'm looking for some guidance or reference implementations of claims authorization that supports fine grained control while also being easy to manage.
Normally, WIF is used with an IDP like ADFS (which sits on top of AD).
The claims are configured on ADFS not WIF. The claims configured on ADFS are sent to WIF in the SAML token. To find the claims configured for the application you have to look at ADFS.
Claims are not dynamic i.e. if a user attribute is changed in AD, the claim will not be updated until the next time the user logs in.
Trying to limit the numbers of claims configured for a user and ensuring that AD is correctly configured are not trivial issues. One way to do this is via groups (AD security roles). ADFS can map these for you.