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
I have 2 web applications, one is ASP.NET MVC 5 + WIF hosted in IIS, another is a web service based on WCF and self-hosted. Both of them are under same domain (so there are no security issues to change cookie format) and referring to the same STS (in same security realm), so theoretically if one user already authenticated, he should be able to access other entities within same security realm without authentication.
However, these 2 websites are using different session token format. For ASP.NET MVC 5 project, it uses WIF implemented standard security session token and serialized to cookie; for WCF web service, it uses its own token/cookie format.
Then we have a problem.
When user navigates from ASP.NET MVC website to WCF web service, because WCF web service cannot recognize WIF session token (FedAuth and FedAuth1), so it redirects user to STS and login again, that is not the biggest problem, the biggest problem is, after use logged in, and POST raw SAML2 token back to WCF web service, WCF web service creates its own format token and tries to set client cookie, it actually doesn't work, I guess maybe there are already FedAuth and FedAuth1 cookie in header so header cannot accommodate more tokens (4K limit?)? Having thought about this for a while, there are are several solutions come into my mind:
Unifying token format. I need to subclass SecurityTokenHandler (maybe also need to subclass CookieHandler), use the same token format that WCF service uses, so when jumps to WCF web service, it can recognize the session token. That needs to dig deep into FAM and SAM.
Force re-login. I can clear FedAuth and FedAuth1 cookies before navigates to WCF web service, it is acceptable that user needs to login again, this is a short term fix, but how can I capture this navigation away event and clear cookie? The only way I think I can do is before I change window.location.href, use jQuery.cookie to clear cookie, I am not sure if it is the correct way, this is my first question.
Adding a cookie translation layer between ASP.NET and WCF, use WIF session token in ASP.NET website, and when jumps to WCF web service, change the token format. But for this solution I don't know how to capture the jump action and how can I get raw SAML2 token? May be I can save it in WSFederationAuthenticationModule_SecurityTokenReceived event handler? But how to deal with multi tokens from multi users and multi sessions?
Are there other better suggestions?
Can someone explain the purpose of the cookies which are sent to the user browser after successful login in Identity Server4. Also I have three smaller related questions at the bottom.
The client is using cookie middleware in ASP.NET Core defined in the Startup.cs file.
app.UseCookieAuthentication()
It's quite obvious which tokens Identity Server created and which cookies the ASP.NET Core middleware creates, but I'm not sure what content each cookie containts.
ASP.NET Core middleware decided to create chunked cookies probably due to the cookie size (4050B + 865B).
I have been trying to find a way of decrypting the cookies to read the values using the Data Protection API provided by ASP.NET Core without any luck.
idsvr
idsvr.session
.AspNetCore.coookie
.AspNetCore.coookieC1
.AspNetCore.coookieC2
.AspNetCore.Antiforgery.
Which cookie contains the id_token, access_token issued by Identity Server?
CookieName can be used to change the name of the cookie created by ASP.NET Core middleware, should different clients share same cookie name or do they need to have separate session cookies?
Can the Identity Server cookies be decrypted by using the Data Protection API?
AFAIK id_token, access_token are not stored in a cookie by default. But you can store them in the session cookie(cookie created by ASP.NET Core middleware) if needed. Here is how it is done for identity server 3 with hybrid flow using OpenID connect OWIN middleware. There should be a similar option for asp.net core middleware as well.
Each client can have same cookie name but they are not required to do so. BY THE WAY, The cookie can only be accessed by the client who created it.
I do not know.
I have an asp.net Web Api 2 / Identity 2 application that requires a user to be authenticated. The authentication works but I notice that when I restart my local development machine and try to access a method that requires authentication then I get a failure.
As my application is unchanged from the asp.net sample then I think it uses cookies to store user data on the client. Where and how does the Server or IIS store information on which users have authenticated? Does it do this just the once or on every HTTP? Is there a difference between my using Token or cookie authentication in the way that the authentication and also authorization is checked on the server?
I think you are misunderstanding how authentication works with ASP.Net. As an example, let me show you some cookie details for a site of mine that uses Identity (note the token is actually in the cookie, the two are not mutually exclusive concepts):
Name __RequestVerificationToken
Value afeILhaIvRr56jXXXXXXXXXXX
Host site.azurewebsites.net
Path /
Expires At end of session
Note that the cookie, by default, expires at the end of your session. That means when you restart your development machine, your cookie is expired and your token is no longer valid.
In particular I have read that with token authentication then there is no need for continual re-authentication every time a request is made to the server
You need to understand that HTTP is a stateless protocol. Each request happens in a vacuum, and therefore you need to pass some data back to the server so that it can tell that the person who authenticated with Request A is really the initiator of Request B. Almost always, that piece of data is from a cookie. So, every request does indeed re-authenticate, and typically with a token in a cookie.
The only piece of data about your session that is stored on the client is the cookie (unless you are doing something atypical). The rest is on the server. How it is stored can vary:
Inproc: Easiest to setup, sessions are stored in process. So when your server or app pool is restarted, that data disappears
State Server Mode: Sessions are stored in process, but outside of the ASP.Net worker process, so the application can be restarted without losing session data
SQL Server: Unsurprisingly, this stores data in a database. Very resilient, but more work to setup. Also your best option if you are on a web farm.
ref: http://msdn.microsoft.com/en-us/library/vstudio/ms178586(v=vs.100).aspx
Expanding on the great answer by Chris, I would like to add that there are two possible models here. In forms authentication (which is the default membership type for asp.net) the cookie can either store authentication information and then it's called a ticket or the information can be stored in session, with the cookie being a simple identifier for "reconnecting" the authenticated session with the requesting client on each subsequent request.
This "reconnecting" happens in the Application_AuthenticateRequest method of the global.asax. If you are using the default forms authentication storage, i.e. an SQL DB created for you by the framework, the reconnection will be done automatically. If you are using a custom authentication store (like accessing active directory yourself or a custom users table structure) you can override the the method and reconnect the authenticated session using your own implementation. In any case, the authentication data is populated in the User.Identity object's different properties. From that point, if you use the [Authorize] attribute, the framework accesses the object to check if the user is indeed authenticated and authorized.
I any case, the authentication information is tied to both the cookie and the session. Assuming your session is InProc, like Chris said, when the session is lost (through timeout, app pool recycle or restart of the dev machine) the server-side of the session is lost and your authentication / session cookie is replaced by a new one on the next request.
EDIT: Ohh... and one more side comment. Make sure you distinguish between authentication and authorization. The client is not re-authenticated on each request. Authentication is the process of providing your credentials and being identified by the server. Authorization is, now that the server has verified who you are, on each request it checks if you are authorized to access the resource you are requesting.
The server doesn't store information about who's authenticated and who isn't. Depending on your authentication mechanism (forms, tokens?), typically, when a user logs in, the server will return some form of authentication token that the client should pass back to the server on each API call.
Without knowing more about your configuration, it's difficult to explain why when you restart your server you have to re-authenticate, it sounds like the authentication token generated by the server is invalidated on restart.
Where and how does the Server or IIS store information on which users have authenticated?
IIS does not store state based on cookie authentication. Everything is determined based on the request. Either a request has the correct encrypted information, or it doesn't. If you look at a default Forms authentication in ASP.NET, you will find a cookie called .ADUAUTH ... this cookie has all the information to authenticate the request. If the cookie is half expired, it will be reset, but that's all IIS does.
Does it do this just the once or on every HTTP?
Every HTTP request is unique, so yes, per HTTP request.
Is there a difference between my using Token or cookie authentication in the way that the authentication and also authorization is checked on the server?
It's always checked on the server: To find out more, check out: How ASP.NET Security Works: http://msdn.microsoft.com/en-us/library/ks310b8y.ASPX
I think my answer could be a little contradicting to all of the above.. But I think If I understand right..
IIS stores inside the memory space of the ASP.NET worker process, i.e the session data in the RAM.
The storing of authentication state depends on the authentication model you are using. For example: if you are using the Federated authentication, through ADFS, then when a user loads your web page he is required to sign in providing his credentials. The ADFS then sets the authentication token which is stored in the session data, the session id is stored as cookies in user's browser. The server has the mapping of Session Id to its session data.
Now the user is authenticated. The ADFS looks for authentication token to mark a user as authenticated.
When you restart the server, the session data is lost as the data is stored in RAM.
There are ways to handle this, there are 3 types of session storage:
1. InProc (Stored in memory space of ASP .NET Worker process - RAM)
2. State Server (Stored out side of ASP .NET worker process, like on cloud Azure storage)
3. SQL Server session storage (Stored in SQL server)
I think you are adopting 1, because of which you encounter the problem.
In cases 2 and 3, the session is not lost when you restart the server.
Several things --
Token based authentication is not really authentication. It is just issuing you a unique token (can be a guid, unique string, etc) and then associating it with something (like your IP address) and saving that association server side (in a database?). Now whenever you use that token, from the client app, the server checks the association already stored and serves or denies or request.
In many ways, it is very similar to using Cookies to maintain authentication. Only, token-auth was designed more for web services operation than for UIs.
In short: Out of the box, the membership provider will run it's authentication method and upon success, it will create an auth ticket/token/cookie that will be stored from the site. In addition to this, there is a session cookie that is stored with the site as well. When you make a page request, it'll pull these things and use them to determine whether or not you are already authenticated. If it finds the ticket and sees that it is still good, it'll allow access.
When you restart your local environment, the session and it's information is destroyed which is why you have to log in again.
There is an entire pipeline in the framework that makes all of this stuff happen (having to do with authentication, authorization, and identity) and there are number of ok articles on the interwebs explaining this, but imo, they're almost all incomplete or hard to follow. If you want a great soup-to-nuts explanation, PluralSight.com has some training videos that will deconstruct and explain the entire pipeline for you. Understanding the pipeline can help you implement your own custom authentication, and I highly recommend it.
I'm writing an ASP.net application that uses Windows Identity Foundation. My ASP.net application uses claims-based authentication with passive redirection to a security token service. This means that when a user accesses the application, they are automatically redirected to the Security Token Service where they receive a security token which identifies them to the application.
In ASP.net, security tokens are stored as cookies.
I want to have something the user can click on in my application that will delete the cookie and redirect them to the Security Token Service to get a new token. In short, make it easy to log out and log in as another user. I try to delete the token-containing cookie in code, but it persists somehow.
How do I remove the token so that the user can log in again and get a new token?
I found the solution. To put it succinctly:
Dim smartWsFederationAuthenticationModule As _
Microsoft.IdentityModel.Web.WSFederationAuthenticationModule = _
HttpContext.Current.ApplicationInstance.Modules("WSFederationAuthenticationModule")
smartWsFederationAuthenticationModule.SignOut(True)
See here for more information: http://garrettvlieger.com/blog/2010/03/refreshing-claims-in-a-wif-claims-aware-application/
I also see that I can get handles to some other parts of the WIF framework this was, as well. It's definitely worth the read.
Cookies are a bit strange. They are managed by the browser and there is no "Method" to delete them. Just deleting them from the Request or Response objects on the server side does not remove them from the browser on the client side.
To "Delete" a cookie you have to set it's expiration date to the past.
See: http://msdn.microsoft.com/en-us/library/ms178195.aspx