After dooing some research i understood there are many ways to implement authentication and authorization in WebAPI 2 ...
I'm looking specifically at Token based authentication
implementing a custom OAuth Provider and injecting it to OWING pipline
implementing an "Authentication" controller which will generate the required token sotre it to the DB and use a custom authorization attribute (can understand the advantage or disadvantage of this way from #1) see here http://www.asp.net/web-api/overview/security/authentication-filters
A full custom authentication framework implementing token authentication like described here http://www.codeproject.com/Articles/630986/Cross-Platform-Authentication-With-ASP-NET-Web-API
What is the best way to go here ?
I am very confused ...
You can use the Microsoft Wilson library which will do the token authentication and validation for you. The latest release of the Wilson library can be found here https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet
It uses the industry protocol OpenId Connect and thus provides a secure way for token authentication in OWIN middleware. It would save you the effort of doing it yourself.
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 new in asp.net core and want to implement authentication and authorization in WEB API 2 project. I am little bit confuse to use basic authentication, bearer token, JWT token or any other. please suggest more preferable
Thanks
Basic auth is as the name suggests, very basic and not very secure, it uses base64 encoding of the username and password so you must use HTTPS if you use it, but best is not to use it at all.
A bearer token is a type of token which effectively gives access to a resource to the "bearer" of the token. Both basic and bearer are used in an HTTP Authorization header.
You can have different formats of bearer tokens, one of which is JWT - JWT is the industry standard so I recommend you use it, and therefore you'll be using bearer tokens.
This article is a good starting point to look into all this in the context of asp.net core. See also this video series and this article goes into more detail about JWT validation.
Edit
To answer your questions in the comments:
OAuth is a standard for users to delegate permissions to apps or websites to access their resources, for example when you allow some web app to post on your behalf to your Facebook feed. Various tokens are used in this process and they're very often JWT. OAuth2 adds authentication via OpenID Connect.
OWIN on the other hand is a standard for web servers which decouples IIS and ASP.NET with the aim of allowing ASP.NET to run on other web servers which implement OWIN and other frameworks generally to run on OWIN compatible servers if those frameworks are OWIN compatible.
Auth0 is an identity platform which can do OAuth and allows you to use JWTs, generally it handles your identity and SSO. IdentityServer is another identity platform with some similar features.
I'd still recommend starting with the articles I linked at the top, don't worry too much about OWIN, and read more about OAuth to determine if you really need it. If you do, I'd recommend IdentityServer.
ASP.NET Core 2.0 and above Web API authentication and authorization
Bearer type JWT Token based authentication
[Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)]
Please implement as following below post
https://fullstackmark.com/post/13/jwt-authentication-with-aspnet-core-2-web-api-angular-5-net-core-identity-and-facebook-login
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'm looking over the auth docs
https://github.com/ServiceStack/ServiceStack/wiki/Authentication-and-authorization
Basically what I would LOOOVE to do is simplify our service auth. Basically say "If this is being run in the context of an authenticated CMS user (in the API) use that person, if user is ANON, check for a JWT in the header, and run in the context of that user"
So I assume this would all be some sort of custom attribute? (I mean ideally I'd like an attribute or something). Right now we just have a method that lives at the top of every call to do this validation... would love to abstract it all out if possible somehow.
Anyone have any suggestions?
Steve
It's not included in the framework itself however there are a couple of external projects that enable token-based authentication with ServiceStack:
StatelessAuthentication
Using IdentityServer 4 with ServiceStack and Angular
Auth0 ServiceStack Integration
ServiceStack JWT Token validation for Auth0
I am struggling with understanding how to implement the following in Web API 2's OWIN pipeline.
I am building an application that will allow users to log in with several third-party identity providers such as Facebook, Twitter, LinkedIn, etc. However, I want the authentication step to be performed entirely client-side. For example, Facebook provides developers a snippet of markup and JavaScript that perform the authentication within the browser, resulting in a Facebook access token--all without any calls to my API.
The Web API templates that ship with Visual Studio 2013 all seem to assume that the API itself is in charge of the authentication flow. I have successfully gotten this style of authentication working, but in my opinion it is not the responsibility of the API to perform this work.
Here is the approach I have been trying to implement (so far unsuccessfully):
Provide endpoints like /authenticate/facebook that accept the appropriate access token and return a JWT with "decoded" claims if the access token is valid. This JWT would have similar claims regardless of the third-party identity provider. For Facebook, I think this involves a call to Graph API's /me endpoint.
Store the JWT in the browser's localStorage for subsequent API calls
Send the JWT in the Authorize header for each API call
Avoid cookies if at all possible
My questions:
Is this an appropriate way to handle third-party authorization?
Should the JWT's expiration match the third-party access token's? I assume yes, but I want to be aware of any caveats here.
Where and how do I store the third-party access tokens for use on subsequent API calls? Do I include them with the JWT?
Is there a template I can use out-of-the-box, or perhaps an online resource that implements authentication and authorization in this way? I don't understand how to use Web API's many classes and features to implement this.
I have this mostly figured out now. I believe my architecture choice is the correct one after much research, specifically into the so-called "assertion flow." I am using Thinktecture's Identity Server 3 project to act as my STS. I am using a custom implementation of ICustomGrantValidator to perform the validation of the Facebook access token and conversion to claims.