I would like to talk about the SPA client authentication. Most of the blog implementations are stores the token into localStorage, sessionStorage or in-memory storage (redux/vuex/ngrx). It depends on your needs. For instance, you don’t need high security with your In-House applications. For other cases, you need to increase your security. Today, I will try to explain that with my best.
Rather than show all the implementations, the post will be clear and simple. You can find the source code at end of the post.
Where should I put my token and other values ?
As I mentioned before, localStorage, sessionStorage and in-memory storages are candidates for this kind of questions. In web, also we have “cookies”. Best part of the cookies are you can manage them from server-side. For example, when a user logged in, you can put the user sensitive content into her/his cookies without handle it from client-side scripts.
Firstly, I would like show difference between handling other storages and cookies. The below code shows a simple comparison with
Secondly, Let’s give some details about the implementation. I will use three cookie property with login. Just focus on
And finally, ASP.NET Core still waits the token from Authorization Header. Therefore, we have to set the token from the cookies. Startup.cs:
HttpOnly and SameSite
Only the cookies without HttpOnly flag are accessible from client-side script. Therefore, you just making things hard for the other people. Also, you will be avoided from XSS and XSRF attacks with
How should I send the token ?
Other storages are accessible from the client-side hence you just write an interceptor and write the token into Authorization Header. After that the server-side handles the authentication.
As I mentioned above, after cookie with HttpOnly flag you couldn’t access the token on client-side.
XMLHttpRequest will access those cookies for us. Whenever there is a request the
XMLHttpRequest sends all the cookies to the server-side.
Note: If your Authentication Server is separated from your website. You can change the SameSite property on cookies. After that XMLHttpRequest or Axios with withCredentials property will do the work.
JWT Token should have a short lifetime. In that case, you should empower your configurations with the refresh token. The definition as follows
Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner).
RFC 6749 - The OAuth 2.0 Authorization Framework
Internet Engineering Task Force (IETF) D. Hardt, Ed. Request for Comments: 6749 Microsoft Obsoletes: 5849 October 2012…
Once a refresh token is used then it should be disposed. Even if the refresh token is exposed it could be used only once. Then when the user login again the stolen refresh token will be invalid.
I will give an example about how you can handle the refresh token. You can call this endpoint from your client-side.
Tokens are not completely safe, but we can increase the security with couple of measures. So cookies are a very well storage for the tokens. And, refresh token will prevent the user from re-login. You can reach the source code from Github.
Have a nice day !