In ASP.NET Core Startup in Configure method when you are configuring piplelines you can use UseIdentity from ASP.NET Core Identity or you can use UseCookieAuthentication. Both of them provide cookie based authentication.
I want to know what is their difference. Is UseIdentity uses UseCookieAuthentication internally? What are advantages and disadvantages of one over another?
Thanks for your explanations.
From the docs which can be found here and here.
Cookie Authentication Middleware:
ASP.NET Core provides cookie middleware which serializes a user principal into an encrypted cookie and then, on subsequent requests, validates the cookie, recreates the principal and assigns it to the User property on HttpContext. If you want to provide your own login screens and user databases you can use the cookie middleware as a standalone feature.
Identity:
ASP.NET Core Identity is a membership system which allows you to add login functionality to your application. Users can create an account and login with a user name and password or they can use an external login providers such as Facebook, Google, Microsoft Account, Twitter and more.
In short Identity builds on just local authentication and provides the ability to perform external authentication as well as baked in solutions for provisioning user accounts.
The pros and cons of each differ depending on your business and both have their own place which I find is usually determine on a case by case basis.
The inner workings for Identity can be found on the github page here.
Is UseIdentity uses UseCookieAuthentication internally?
Yes.
However, both UseIdentity and UseCookieAuthentication will be deprecated in Auth 2.0.
UseIdentity
UseCookieAuthentication
services.AddCookieAuthentication() and app.UseAuthentication() will be used instead.
Important note: Don't use UseCookieAuthentication, if you have UseIdentity. I mixed them together in a project. Claim-based authorization redirected user to LoginPage instead of AccessDenied page.
Related
In one of my project need to consume JWT token from asp.net core web application. My trial project is on github https://github.com/SapanPatibandha/JWTAuthentication
This has one server JWTAuthentication which is generating jwt token base on username and password.
Second component is AnyAPI which method is protected by self verification of JWT.
Third important part and where I have problem is Web application.
Need to create login screen in this application, base on this user detail call login api from JWTAuthentication and use that token for all further use of api from that web application.
I am not sure about middleware configuration and how to store this token on web application.
Thanks
IMO, What you asking for is a journey that need some investigating time, that's not what could be answered shortly, so... I'm gonna make this as compact as possible
What you're doing in the repo is hand-generate and validate Jwt Token. If that's required, investigate these stuff:
Generating Jwt on central identity provider server (which you currently have)
Validate Jwt on api resource (which you currently comment that out)
On application(seems like you make use of classic MVC or razor page), create login form that use ajax to get Jwt from identity provider server, store it on client side (browser), then attach it with every request that make use of AnyAPI, by cookie or header or something you saw reasonable. Or if you choose to save the token on Server side, implement your own session-Jwt mapping logic(Actually, some kind of Js SPA would be more suitable for this kind of approach).
Another approach would be implement a more proper Oauth implementation. I consider 2 most widely acknowledged in .net ecosystem would be Identity Server and OpenIdDict. Highly recommend to check them out.
What is the recommended approach for user management with IdentityServer4 and Active Directory?
I have started with the IdentityServer4 ASP.NET Core interactive quick start and all is working well. However, the sample code uses the TestUserStore, TestUserProfileService etc., and it seems prudent to replace usage of these.
The 'real-world' alternative seems to be using ASP.NET Core Identity, however this persists user details to the IdentityServer database. Given that IdentityServer isn't the source of truth for this data, this is an odd fit.
Apart from the "test" nature of the quick start classes, these are serving our needs well. Our IdentityServer instance is for internal staff in a small organisation, so the in-memory nature of these stores isn't a problem.
This seems to be a fairly common use-case, so I must be missing something. Can one just delegate all user profile calls to Active Directory? Is there any out of the box code for this?
Identity Server is an implementation of OAuth 2.0 and OpenIDConnect(Built upon OAuth2.0). The key point of OAuth 2.0 is to pretect resource such as WebApi based on Access Token. So what does OAuth 2.0 provided is Authorization.
Identity Server can provide Authenticate service provided by ASP.NET Core Identity, as specified in This Document
In your case, you'd like to delegate the authenticate part to AD, and authorization part to Identity Server. You can refer to This document to enable windows authenticate in your asp.net core application
I resolved this by implementing and registering an IProfileService for Active Directory. It still seems oddly hand-rolled, but seems to do the trick.
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 developing ASP NET Core Web API and I am confused by choosing the authentication method. I used to apply default Asp Net Identity authentication, but recently I've known about JWT. So I've implemented Authentication almost as it done in this article: https://stormpath.com/blog/token-authentication-asp-net-core.
But I can't understand the benefits of this JWT. With simple Asp Net Identity Authentication, I don't care about token storage etc. I only need to log in with signInManager and use authorized methods until logout. With JWT I need to think about the token store, expiration, and other difficulties. So, what're the benefits of this JWT? How can I store this JWT token after login? Furthermore, should I even use this JWT? In my case, I need simple authentication for simple WebApi which will be used by one or little bit more users. I've also heard about OpenIddict, Auth0, IdentityServer, so what's the difference between all of these authentication mechanisms?
This is the way I understand this, split in to 3 logical parts.
Authentication Server - this will authenticate and issue the JWT token, when the API need's to validate the token it will send the token to this server to validate it.
Client - this is what serves your web pages, or you app perhaps. This is what will need to request and store the the JWT token. The client will need to pass the token to the api every time it requests data.
API - this is what serves the information and needs to validate the token with the Authentication Server.
So, what're the benefits of this JWT?
JWT is issued to the client and stored on the client side. Having JWT allows multiple client's (App's or Websites) use the same authentication server which distributes JWT and states which API's the client's can use and how.
How can I store this JWT token after login?
I only tried to store it in an Ionic 2 app which uses angular 2 which has a storage module. But i'm pretty sure numerous people have done this already and asked this question:
Simple JWT authentication in ASP.NET Core 1.0 Web API
Token Based Authentication in ASP.NET Core (refreshed)
Update
If your front end is made purely html/js/css and doesn't have a back end to accommodate it you would store your token in local storage, there a multiple npm packages that help you with this like this one. You want to look for Implicit flow.
Otherwise if you do have a back end that comes with your front end you want to store the token in a session/database your pick, there are 3rd party providers to do this like IdentityServer4. You want to use Hybrid flow
Furthermore, should I even use this JWT? In my case, I need simple
authentication for simple WebApi which will be used by one or little
bit more users.
The reason for the whole separation of concerns is performance so you don't really need it since it's just one or a little more users. Do it because it's a learning experience, JWT is not easy to setup from the beginning and will require you to do a lot of reading and you will fail and you will be frustrated but at the end you will know how to set it up and how it works
I've also heard about OpenIddict, Auth0, IdentityServer, so what's the difference between all of these authentication mechanisms?
So what you did in the Stormpath tutorial is NOT production ready. That is just a little demo, to help you understand what JWT is and how it works. The above mentioned are complete libraries that tackle all the heavy lifting and do not require you to built the whole thing from scratch. And the main difference between them is the scope that they cover.
I personally used IS4 and it had me crying no more than 2 times (It was simpler than I thought):
http://identityserver4.readthedocs.io/en/release/
https://github.com/openiddict/openiddict-core
https://auth0.com/docs/quickstart/webapp/aspnet-core/00-intro
Use tokens (JWT) if you have multiple applications or services (web, mobile, other services) connection to your API. Benefits: Stateless, Scalability, No cookie, no CORS problems (if you allow it).
If your API will be used by only one web application use the default ASP default authentication system. Its easier to set up.
If you webapi and user interface are hosted in the same web application, token bases security does not buy you anything over the cookie based authentication provided by the built in authentication. That's because the authentication cookie gets sent back to the keep application on every HTTP request. When you make calls to a website other than the one you signed in on those cookies do not get sent. So JSON Web Tokens (JWT) provide a standard format for browser to send identity information to a website when a cookie isn't an option.
If your Web Api is to be accessed by AJAX calls then JWT may be a desired choice, but not mandatory. judging by the description of your app,it seems to me that the default authentication system can serve you well.
Auth2 is the authentication mechanism that enable external login such as Facebook. It is part of the default authentication system, and you need not do much in order to employ it in your app.
OpenIddict sits on top of Auth2. It is part of the default authentication system, and you need not do much in order to employ it in your app. It is the authentication mechanism that enable external login such as Google+
IdentityServer may be used for large Wep Api that is accessed by Ajax calls. As for instance, you can use IdentityServer to authenticate users longing to a front end Angular app.
Once again, the default authentication system can serve you well.
Hope this helps...
I have been looking at the Thinktecture.IdentityModel.40 library as a way of handling the security of my Asp.Net WebApi. One point I don't understand is the following, and this is my question.
When the user authenticates the first time, they need to supply their username and password. If they are authenticated, they are issued a token to use for all the other calls.
Using the above library, I use the method, AddBasicAuthentication to the security config.
Will this by default use the token issuing mechanism, or do I need to use the AddSimpleWebToken?
And If so, how do I tie the two mechanisms together?
There is no token issuance yet. I am working on that feature.