I am building a SPA using React and Redux on top of dotnet core 2.0. Unfortunately, the vs2017 template for this does not include Authentication/Authorization.
In looking around, I saw many people talking about the use of JWT's and suggesting things like Identity Server or OpenIddict to handle this, but I have only ever used ASP.NET identity to handle security before.
My question is, is it possible to secure a react app by using ASP.NET identity alone, and if so, why do so many people jump straight to JWT's as the solution for securing SPA apps?
Is token based authentication the only method that works with a SPA app, or can I use Cookie based authentication?
I will try to answer by your questions.
Q.1. Is it possible to secure a react app by using aspnet identity alone, and if so, why do so many people jump straight to JWT's as the solution for securing SPA apps?
Q.2. Is token based authentication the only method that works with a SPA app, or can I use Cookie based authentication?
Answer To First Question(this question technically related to difference between cookie based and token based authentication approach.)
Cookie based authentication system
cookie based session is StateFull. as here server needs track of active session,while on front end/client end a cookie is created that holds a session identifier.
you can secure your web api using cookie based authentication system. but in a very limited scope, because ,cookie based system doesn't work well, on native clients or suppose if your web api is going to be consumed by some other web api,
Token based authentication system
it is StateLess as server doesn't keep here the track of which token are issued or which users are log in.
Here server needs to verify only the validity of the token. so token based approach is more decupled than cokie based.
Sources
https://auth0.com/blog/cookies-vs-tokens-definitive-guide/
Update Above(Auth0) link not working any more Updated Link
https://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/secure-net-microservices-web-applications/
Answer To Second Question
Yes you can implement cookie based authentication in spa by using OWIN Cookie Authentication middileware .
you can find more information regarding it on following link.
https://brockallen.com/2013/10/24/a-primer-on-owin-cookie-authentication-middleware-for-the-asp-net-developer/
Hope above will help.
If you are going to have React and API in one domain, and the SPA would be the only client of API it may be recommended to use cookie based authentication with SameSite Cookies.
https://www.scottbrady91.com/OAuth/Cheat-Sheet-OAuth-for-Browser-Based-Applications
https://brockallen.com/2019/01/03/the-state-of-the-implicit-flow-in-oauth2/
(section same-domain apps)
longer post: https://blog.cdivilly.com/2020/06/10/oauth-browser-apps
Related
I work on an application where I have a separate MVC layer and Web API Layer, both have the same authentication mechanism, I have chosen the individual accounts authentication option while adding the projects. The web api service layer will be directly accessed by some other mobile clients also.
But when the user logs in through MVC he should be able to access Web Api seamlessly, but I don’t want to really pass the username and password from MVC to the Web Api layer, I am told it is a bad practice. but i need to authenticate and authorize my user, so the only option i have thought of is to have a default account at Web API level to issue tokens, and this will be called from MVC post the authentication and a token will be returned which is written to a cookie in the client. Now the Ajax calls from the UI can use this bearer token and get the job done.
The only glitch I have here is that, because I am using a default account I need user details again for authorization at service level, though I am doing authorization at my UI level, the user can spoof the system. I was lost here and came up with a solution like, when the user logs in to MVC will send across user details also along with the call to get the WebAPI token and issue another token to the user so that the user uses both of the tokens to make a call to web api from MVC.
I am not sure if this works or if it is even the best way. I just wanted to check, how I should go from here. Any help on this will be really great.
This is a really good example of integration - I know they use Angular as the client but you can learn from this:
http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/
Check this section to see how they decouple the API from the front end (Part of the same article).
http://bitoftech.net/2014/09/24/decouple-owin-authorization-server-resource-server-oauth-2-0-web-api/
In my solution I am using Thinktecture IdentityServer.
I wanted to introduce the remember me feature (persistant cookie) so I used AllowRememberMe option described here: https://identityserver.github.io/Documentation/docsv2/configuration/authenticationOptions.html
and that is working good but the persistant cookie is created only for IdentityServer instance - not for the client website which called for authentication.
My question is: Is there out of the box solution to achieve that? or do I have somehow pass deatils about cookie expiration through claims or so?
Of course identity server can only issue cookies for itself - not your applications. You would need to do that in your application code.
I'm building a mobile application (that might also later become a web application). The server side is a ASP.NET MVC + Web API application and I'm thinking about ways how I could implement the service's user management and authentication.
How should I implement the registration/login screen in the app? Offer native app forms, that will send just API requests to the service or is it preferable to show a web browser component and display the website's login page and then extract a token after the user logs in? I see the first option is more user friendly, but the second one will let me change the login / registration page (like for example adding external authentication providers) without breaking older versions of the app.
My second question is regarding the external authentication providers. ASP.NET Identity has good support for them and it is quite possible to let users register using Facebook or some other OAuth2 provider. Does it make sense to add support for external authentication providers when I plan to expose the app's API publicly? Are there any reasons why that is not a good idea?
Your first option is best if you believe your users will trust you to manage their passwords. You make a secure call to your service, have the service produce a bearer token as the result. That would be an anonymous call. I used the answer from this question to get me going down that path:
Get IPrincipal from OAuth Bearer Token in OWIN
If your users are less likely to trust you with their credentials, then the web view and external provider is a good alternative. You would need to work with providers that support the "Implicit Grant Flow" since don't want to share the apps clientid and client secret on the mobile device. This approach involves using a web view to login in, and then capturing the token on the client uri fragment on the response. I think it is on a location header, but don't have a working example in front of me. Something like:
https://your.domain.com/#access_token = 8473987927394723943294
you would pass that token with each api call afterwards .
Good luck!
There is an existing mvc 3 application that is using asp.net Membership authentication (subclass of System.Web.Security.MembershipProvider). This application was only accessed using web browser.
Now, there is a need for the application to support a Mobile App, and I have already introduced WebApi 2 Controllers into the project for handling the Mobile App requests.
The problem is that I don't have a clear thought of how to Authenticate the Mobile App users.
It seems that I have to provide Token type authenticating mechanism where the Mobile App has to submit the Token (issued after authenticating) with each request. But I am not sure how to implement it (like what frameworks/packages to use), and get it working side by side with the existing MembershipProvider
So, how do I provide a way to authenticate Web Api requests, and also retain existing asp.net MembershipProvider for MVC Controller requests.
Also, if this could be done better in some other way ?
It doesn't have to be "token" that authenticate mobile users.
The notion of tokens used to authenticate webapi requests got a lot of attention because of the OAuth2 protocol that has been adopted to the .NET world by the DotnetOpenAuth and then the OWIN. OAuth2 supports multiple "flows" and what is interesting is that beside "passive" flows (where browser redirects to an external login page) there are also "active" flows (designed for active clients like mobile apps).
Thus, switching to OAuth2 means that you are using a coherent authentication protocol supporting all major scenarios.
One of the possible approaches for you (and you seem to be interested) is to adopt the token approach to authenticate webapi requests. This is possible but this means that you have two different authentication approaches side-by-side, the cookie-based forms authentication for passive clients and token-based authentication for active clients.
I would say this kind of smells.
I would rather think of a uniform approach.
Either move towards OAuth2 completely, which means you adopt DotnetOpenAuth/OWIN for both passive and active clients.
Or you stick with Forms Authentication and just enable it for your active clients.
The latter is rather simple. Instead of carrying tokens, your active clients carry forms authentication cookie. To issue such cookies, you just expose an anonymous webapi method that expects a login and password and appends a forms cookie to the response.
Assuming you clients support cookies, forms cookie issued by the server are used in consecutive requests and all you have to do is to have the Authorize attribute over your web api methods. The forms module will pick up the cookie and populate the IPrincipal for the lifetime of requests just like it does for regular requests.
To summarize:
Moving towards token-based authentication:
Pros:
in future you could easily handle more complicated authentication scenarios (like for example using external authentication providers)
token-based OAuth2 is commonly used nowadays so you can more easily integrate with other applications
Cons:
migration could cost: you first have to gain the knowledge, do some R&D and then migrate
Sticking with forms authentication:
Pros:
you already have it and you just enable it for active clients
Cons:
forms authentication is not really "an authentication protocol". This means there is no obvious way to easily integrate with external authentication providers/consumers
I am very new in web api security. I have used form authentication technique. when user logs in, a token is created and stored as a cookie in user's web browser. On each request the token is varified and if user is authenticated and authorized user is given access to the service.
but I think this approach does nothing in web api security. cookies can easily be copied and pasted in other browser and anyone can get the service.
I am thinking to use App key and secret along with form authentication. I am not suggested to use third party service like Oauth for authentication. I am not Sure about the Implementation of app key and secret that how it exactly works.
Please provide better way to secure my web api wihtout using third party services and to prevent cookie hijacking etc. What actions are performed to build a strengthly secure web api.
The forms authentication is good enough. You can also do the following:
Use anti-forgery (antifrogery) tokens. Check this or this
It will also be great if on sensitive actions you check if the call to the function was made from the same site or not.You can implement your own action filter for this. (check if the referral site is your site, or the expected site)
Edited:
Thanks guys for your comments. I guess you are right. Well authentication cookies in ASP are created as httpOnly cookies which means even if the site had some XSS vulnerabilities it will still be safe and cant be stolen. I would also suggest to use https everywhere if the site is used for sensitive operations (like a bank) to make sure the cookies are perfectly safe.