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.
Related
Like cookie authentication, I was trying to implement Session based authentication in my MVC Core 5.0 application but could not find any example to implement it. ? I have seen various example of storing the data in session and retrieving back but nowhere found for authentication and authorization purpose. Does session based authentication exists or just used to store the data for state management purpose? I thought Session authentication with Redis will be best for security so trying to implement it.
What other options I have for authentication so that I can choose best one?
There's a lot of out-of-the-box authentication implementations in aspnetcore like Cookies, JWT, OpenIdConnection, WsFederation, Certificate, ...etc. to name a few.
There's no best or worse when it comes to choosing the method of authentication (e.g., You can't substitute certificate authentication for cookies) each authentication method has proper use. However, if you decided to go with JWT, for example, you can have a less-secured JWT and a more-secured JWT authentication, and that will be due to how you generate and validate the JWT token.
Instead of asking what is the best authentication method?. A better question will be what's the best authentication method for your specific use case.
HTTP is a stateless protocol, and sessions are a "hacky" way to track state in HTTP that's why I would advise you against storing any user claims or authentication information in a session store. There's a good explanation here why you should avoid sessions where possible. But of course, if you still want to do it this answer explains how.
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...
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.
Authentication is a bit over the top for me.
My understanding is:
Client performs the login
API or authentication server responds with a token
Client calls API (includes a header which holds the token)
API checks if the token is valid and if valid responds with a resource
I checked several options:
IdentityServer4
Has the advantage to easily implement 3rd party authentication like Facebook. You can easily use the ASP.NET Core identities to authorize your API based on roles.
Custom (simple) JWT authentication
Reference: ASP.NET Core Token Authentication Guide
With this approach, you have to make your own identity user and fetch it from a database.
Cookie authentication
The client holds the token in a cookie when sending a request you have to send it too.
My front-end is written in JS and back-end is ASP.NET Core, so it's CORS.
I don't know what should I use and why? Why do many recommend to use IdentityServer4; isn't the simple custom authentication enough?
(I have problems with the IdentityUser properties and the "hidden" database checks)
The problem with authentication is that it may be simple to write a few lines of code that accomplish the end goal of authenticating your users, but it's really complex to do so in a way that you won't regret it later; aka my application got owned.
One of the steps to take to try to prevent that from happening is don't try to reinvent the wheel and stick to using current standards. However, even with standards, you need to implement them accordingly and that is why you probably see recommendations like the one you mentioned. I would actually make the same type of recommendation my self, delegate as much as you can to third-party libraries like IdentityServer4 or cloud services like Auth0. (you should know I work at Auth0, so you can consider me biased; however, for a non-biased recommendation you can check ThoughtWorks Technology Radar).
Also, if you store tokens in cookies, although the storage and transmission of the token happen differently this is still a token based-authentication system; for more on the possible implications of choosing a client-side token storage approach check where to save a JWT in a browser-based application.
In relation to CORS, you did not make that explicit, so I thought it may be worthwhile to mention it. You only need to actually worry about CORS if you deploy your front-end and back-end in separate domains because even if development happens in isolation if they share a domain CORS is one less thing you need to worry about.
Conclusion
For a front-end browser-based application talking with a REST API, the most common approach is to go with token-based authentication that relies on OAuth 2.0 protocol to perform the actual issuance of the tokens. Additionally, you should aim to delegate token issuance to a third-party (IdentityServer4 or other) so that you don't need to implement or maintain that part of the system and only need to consume/validate the generated tokens.
I have to implement public WCF service which can be consumed by known client. I also want to authenticate client using custom identity (not windows authentication).
I have explored WCF security for authentication with custom Username and Password. Since I have to implement the solution for Hetrogenious network, I cannot use windows authentication.
I have found two ways through which we can incorporate custom authentication in WCF. I have few queries on each of the approaches as below.
1) Through "UserNamePasswordValidator" class. We can create custom username password validator and validate user from the database. This approach is perfectly fine to implement SSO (Single Sign On) as each request has credentials in SOAP header. Client doesn't have to validate himself before each request.
Questions:
Is this approach is easily extensible for Authorization as well? Since authentication happens before service call by getting credentials from the SOAP header. Also credentials are not a part of ObjectContext, I have feeling that authorization approach is not straightforward.
To follow this approach we need to use Brokered Authentication pattern and for this we need third party certificate. Is this advisible to go with this approach as we have to add cost of certificate in a project.
If we use message security to encript the message why we need a certificate? Just for Client identity? Cann't we just use self signed certificate in production since we know who will consume this service?
2) Through "ServiceAuthenticationManager" class. I know only one approach using this class and that is to implement solution using Direct authetication pattern. Also after authenticate user, we need to supply it's identity or token through custom header for all subsequent request coming to service to implement SSO (Single Sign On)
Questions:
Is this a valid approach for public service? Should we enforce user to supply credentials (or token once provided by our service once it is authenticated) via custom header in each request?
This approach doesn't required certification and so we can save its cost to the project. Is this enough reason to pick this approach?
Personally I feel the first approach is easy to implement and it is more standard way to implement authentication in WCF service but the only problem is we need third party certificate.
Please answer my query and if possible suggest the best approach for my requirement.
Thanks,
Ankur