I'm implementing security for my React SPA using Spring Security on the backend. After a lot of reading, I opted for the following approach :
HTTPS everywhere
POST /login takes credentials returns JWT_TOKEN & XSRF_TOKEN in cookie form. I build the JWT_TOKEN myself whereas Spring Security handles the XSRF_TOKEN. Both cookies are Secured and SameSite=Strict. The JWT token is HttpOnly.
Subsequent API calls require the X-XSRF-TOKEN header. This is read from the aforementionned cookie. Both are sent and Spring Security compares them. JWT is automatically sent and checked in a Filter.
Every time a XSRF token is used, Spring Security generates a new one to prevent session-fixation attacks
XSS protections are applied by Spring Security
So now I'm wondering about refresh tokens. I'm reading a lot of contradictory info out there. Do I need them with this setup? If so how best to handle this ?
Many Thanks
In general, as its name says, the refresh token changes from one token to another. Typically they are used in OAuth protocol-based authentication. They are useful when an access token has expired, but the user's session is still valid.
First, JWTs are a great choice for access tokens. They have claims that match the access tokens requirements, such as: exp, iat, jti, sub, etc. But, when using a cookie-based authentication there is no need for access tokens and possibly no need for JWT.
As you said, your JWT_TOKEN is being set as an HttpOnly cookie, which means that only the server has access to it. JWT is useful for sharing the initial state between the client and server, and vice-versa. If your server is just taking it to look up the database, you don't need a JWT, you are just using a session concept, and keeping session data on a JWT may not be a good practice.
Second, if your authenticated cookie data will live at /login and die at /logout, there is no need for refresh tokens. Refresh tokens are an exchange key for short-life access tokens. Instead, your cookies keep the session live and don't need to be exchanged by something else.
For example, if the user uses the /login route to exchange your username and password for one short life access_token. He may need the refresh_token to get a new access_token without needing to send his username and password again.
If you are using the OAuth protocol or similar, refresh tokens are essential to provide a more seamless experience for your users and avoid the inconvenience of repeatedly having to re-enter their credentials. But even on OAuth, they are not mandatory.
Related
We are trying to implement an application where UI is in angular and backend is in Spring boot.
We need to implement openId and oauth2 in our application.
Backend api's needs to be more secure.
I am just confusing which oauth flow to be used either authorization grant flow and password grant flow.
Can any one suggest me which one need to use in this scenario and why?
Storing tokens in the front end is not recommended. It also distributes token handling logic across FE and BE because BE will have to validate tokens on each request anyway.
Therefore to avoid handling and refreshing tokens in the frontend and to simplify the overall architecture, you can implement authorization code flow in Spring Boot. This will also reduce the risk of XSS exposure in the FE.
You could implement a dedicated endpoint that initiates the flow and receives code from identity server. It then exchanges this code for id token and stores it. Then it creates an HttpOnly, strict SameOrigin session cookie for the front end. From that point onwards all calls to the API inside your Spring Boot will automatically carry this cookie without any additional code on the FE.
To eliminate token storage on the BE, you could even put token inside the cookie. However, the token may be quite large and may need to be broken into chunks. This would not affect FE in any way.
You will need to check token expiry on each API call inside the BE and refresh token in the backend as well. This will keep user session seamless. If token can not be refreshed due to revocation or refresh token expiry, the API would have to return 401 and the FE would need to initiate re-login.
I have implemented a spring boot application which does authentication and authorization using Spring OAuth2.
I am using JDBC token store to main the token issued to the client for performing Custom claim verification and some other user status verification during application run-time.
The question is, since i had used traditional JSESSIONID with CSRF token, i cannot find any advantage with the new OAuth standards because after login i would store the user details in the session and retrieve it whenever needed similarly for OAuth i store the User details in the JWT token itself and decode the token every time to get the user information, also i need to hit the database anyway for custom claim verification such as JTI verification .
Everyone says JWT is for stateless application but with JDBC token store i'm holding all the token that is issued to each client. Also there is an additional overhead to purge the expired token which will be done automatically with Session. Also i'm using refresh token as the way to implement session timeout.
Therefore can anyone explain me, when should i use JSESSIONID and when to use JWT ? My application is running on AWS architecture.
From my experience, cookie-based authentication sufficiently complicates scaling and load-balancing. If you have authenticated via the first service replica, your cookie will be not appliable to another replica, cause all sessions are stored in memory. So, if you want to scale your service in the future, session-based authentication can make things much more complex.
If I have a single page web application with a Laravel back end, my best option for authentication seems to be Passport with a Password Grant authentication flow. In Passport, this returns an access token and a refresh token.
For security, I would like to issue a short lived access token and refresh it when it expires. However, all the available information about using OAuth with a Javascript application says "don't make your refresh token accessible to the front end" because it's long-lived and can be used by others to generate new access tokens.
For example:
A Single-Page Application (normally implementing Implicit Flow) should
not ever receive a Refresh Token. A Refresh Token is essentially a
user credential that allows a user to remain authenticated
indefinitely. This sensitive information should be stored securely and
not exposed client-side in a browser.
Does this mean that a browser-based SPA cannot use refresh tokens and must, therefore, only issue access tokens that expire after a reasonable "session" length, forcing the user to log in again afterwards?
Otherwise, is there a suitable way to implement short-lifespan access tokens and refresh tokens in a Laravel Passport app with Password Grant authentication, while maintaining good security?
There is no harm in storing refresh token, as they can be used to get another access token after the access token(short lived as you mentioned) expires which create a good user experience.
I understand that JWT are stateless tokens that store signed information about the client's claim and are passed to a server via the Authorization HTTP header.
My question is, why do we need JWT when we already have client sessions (https://github.com/mozilla/node-client-sessions)? Client sessions are conceptually the same. They're cookies that contained signed information which when verified means the cookie hasn't been tempered with. Also, client sessions are stored in a cookie and passed via the Cookie HTTP header. It's the same thing only using different words. Am I wrong?
So, why is JWT even around? I could understand that maybe the point is to standardize the way authentication tokens work, but we got along fine without a session ID based standard (each implementation did things their own way). Also, why would the JWT not use cookies as a means of transfer. With cookies, you wouldn't need explicitly send the correct header for every request (simplifying Ajax requests).
Am I missing something?
JWT tokens are signed JSON formatted documents that assert claims about a user (or any principal). If you trust the issuer of the token, you trust the claims in the token and can make authorization decisions based on this.
JWT tokens are often used for calling external Web APIs. These APIs do not necessarily live on the same domain as your website and therefore cannot use the same cookies as your site. JWT tokens are used in REST services as they do not need any session info stored on the server. Using JWT tokens is also not vulnarable to CSRF attacks.
I have implemented the usual username/password login process with Shiro for my single page webapp which will submit the username and password over https in production. I use a REST back end rather than a typical MVC framework of any sort to facilitate my SPA. Typically with a REST API a BasicAuth is used to log in, and in response if successful an encrypted token is returned either as a cookie or a response header. Subsequent calls would return the cookie or header to avoid having to resend username and password. Usually the token is an ecnrypted username possibly with some other info that can be derived on the server side either as a session token or something else.
Anyway, as I said I am using Shiro and I understand Shiro can use multiple realms for authentication and authorization. What I am trying to do for my web site is require the initial username/password login, then after a user is logged in, somehow avoid the Shiro UsernamePassword authentication process and instead use the token check process.
I think the right way is to provide my own custom authentication realm and credentials matcher.. and I have a public domain SHA256 salted password bit of code that stores the salt, iterations and password in one string that I'd like to use. What I am not sure of is how to configure the shiro.ini... do I need to provide two custom classes, one for my own username/password for initial login, then another for my token authentication? Or can I utilize the built-in shiro usernamePassword, and will it's rememberMe feature be good enough in jquery $.ajax() calls? Perhaps I can use the Shiro implementation but also need to attach the shiro rememberMe cookie to all my $.ajax() calls?
Just a little confused really on the best approach to provide good username/password initial login and subsequent calls without needing to resent username/password... and to support session invalidation and logout functionality.
Another thought is to not use Shiro, instead use my own servlet filter to check for the initial login, if authenticated, return the response header (or cookie) myself with my own encrypted token that I keep in HttpSession or in a database back end for the duration of the session, and make sure in my jquery ajax that after each response to look for the token, and resend it in the subsequent requests.
Thanks