A lot of questions have already been asked on the topic of storing JWT tokens securely when dealing with a browser-based application. The consensus seems to be that http-only, secure cookies should be used. However, many variations seem to exist on storing JWT tokens when both short-lived access tokens and longer-lived refresh tokens are involved.
I have identified the following variations:
1. Store both JWT access token and refresh token in http-only, secure cookies
Pros:
Access token and refresh token cannot be accessed from Javascript
Cons:
Introduces CSRF vulnerabilities so CSRF token must be added as well
The top answer here advises to add CSRF tokens: https://stackoverflow.com/a/37396572/6735966
2. Store a JWT access token in memory and refresh token in http-only, secure cookie
Pros:
Refresh token cannot be accessed from Javascript
Access token sent through Javascript so access token is not vulnerable to CSRF
Refresh cookie can only be used to obtain new access token. With the correct CORS setup, reading the access token from the response is not possible through a cross-site request by a malicious party. Therefore, this approach seems safe from CSRF.
Cons:
Access token can be accessed through Javascript (but access token expires quickly)
Recommended here but received a lot less votes than the top post: https://stackoverflow.com/a/63593954/6735966
3. Store a refresh token in memory and JWT access token in http-only, secure cookie
Pros:
Access token cannot be accessed from Javascript
Refresh token sent through Javascript so refresh token is not vulnerable to CSRF
Cons:
Longer-lived refresh token can be accessed from Javascript
Access token is vulnerable to CSRF
A similar approach is described in the top answer here: https://stackoverflow.com/a/54378384/6735966
Considering the pros and cons storing a JWT access token in memory and refresh token in http-only, secure cookie definitely seems like a good idea to me. However, even though there are many questions on this topic, none of the top voted answers even consider this approach. Therefore my question is: Why not store JWT access token in memory and refresh token in cookie and instead use one of the other approaches?
Storing the cookie in memory would work, but one issue is if you have multiple instances of the same client.
An alternative is to do it like they do in ASP.NET core, where by default the cookies are stored encrypted in the session cookie. However, this cookie can't be used to access any API's, as it is inaccessible from JavaScript. Also, to avoid the CSRF issues, you typically add the common antiforgery token/cookie to prevent CSRF attacks.
So, the most way is to store the tokens in ASP.NET Core is in the session cookie. But at the sametime, this make the cookie to grow quite a bit, so when you feel the cookie size grows to big, then you start looking at storing them in memory or in database/Redis storage.
In .NET for example, the support for this is already built in by using a SessionStore. The picture below tries to show how this works where the SessionKey is stored in the cookie and then tokens are stored in memory/backend.
Yes, this is how it works in ASP.NET Core and I am sure you can find the similar approaches in other platforms as well.
An alternative is to look at using the BFF pattern that seems to get more and more popular.
Related
I've always been under the impression that storing both of these tokens in an httpOnly cookie is secure enough, but been lately reading some people only store the refresh token in the cookie, and since the accessToken is short lived, they store it somewhere in app memory (context, redux, whatever). Since the entire goal of the refresh token is to fetch a new access token, the access token doesn't have to be stored in a cookie, but has it's disadvantages if you don't?
I think the issue for me is that with SSR, you can't access the access token on the server (NextJS for example), so you can't do prefetch/other operations on the server when you need to access token values right?
I assume that even context is an attack vector, so storing both of those tokens within the cookies is the safest?
It seems its more of a debate than being frowned upon in terms of storing both tokens in a cookie at the same time.
Storing both tokens in HTTP-only cookies is the safest way and is currently recommended as a security best practice for SPAs. However, this has some limitations and sometimes it's more convenient to store the access token in memory. When you have the access token in a cookie then you need your own backend that will handle those cookies. E.g., if you're calling APIs that require access tokens in the Authorization header, and you're not in control of those APIs, then you somehow have to translate the cookie to the header. Some people find it easier to just keep the access token in memory and call the APIs directly, without any intermediary backend components. Not all systems require the toughest security standards. Sometimes it's about finding the balance between robust security and good developer or user experience.
Current Setup
I'm currently building an application, and have just finished implementing an OAuth authentication server. This is my first "real" attempt at a project that has a legitimate user authentication and management component, so much of this is new to me.
I've implemented the OAuth specification. This means the following:
The authentication is deployed on a separate webserver with a separate DB than the application server.
The auth server logs in a user, and issues them two tokens. One is a JWT access token that contains information about their user identity. This has a short-lived 15 minutes expiry. The second token is a refresh-token. This is a single-use token with a 7 day expiry. It is used to fetch another access token with the application server returns a 401 (the access token has expired).
The application server shares a secret key with the auth server, and has middleware that verifies the JWT access token.
Concerns
My concern is that I've over-engineered a project that didn't need this much complexity. Since the auth/app are distinct, this means that my client code needs to be aware of, and handle refresh token rotation. It needs to interpret 401s, and fetch another access token.
As far as I can tell from my reading, this wouldn't be necessary with simple session cookies that persist. The cookie is just included in requests to my domain. If I killed this approach, and just had my server do a DB lookup on a signed session cookie - I would avoid a lot of this client complexity.
One consideration is that I’m using a React SPA frontend client. This is also new territory for me, so I’m not sure whether or not this changes the situation.
As I said above, I'm new to a lot of this so could use some advice from people who have worked in this space for longer and have the experience. Is OAuth worth the hassle?
Options
OAuth with access tokens (JWTs) and refresh tokens:
Pros: Provides a secure and scalable way to handle user sessions.
Cons: Client needs to be aware of refresh token rotation procedure and handle 401 responses by using the refresh token to request a new access token, which can add complexity to the client-side code. Also adds complexity (and cost) to the AWS infra stuff. I need to know how to get the auth server and app server on the same base URI. Also makes my local dev environment a little more involved.
Server-side sessions using signed cookies:
Pros: Simpler for the client, as it does not need to handle refresh tokens or 401 responses.
Cons: Server needs to manage session state, which can be more resource-intensive. This means a DB call on every request.
If I have an app and an api. If the app logs in through authorization server and sends the authorization: Bearer xxx header with each request, the api can verify the token locally.
When the user logs out (through the auth server), but the token has not yet expired if someone retrieves this token they will be able to make requests (if the authentication of the token is done locally on the server), is that correct? If thats the case, why is such a logout flow considered secure?
Edit: Clarifying the main question: why PKCE flow is considered secure if when a user logs out their access token is still valid (given we do local token verification)
BEHAVIOUR OVERVIEW
With OAuth there is a greater separation of concerns than in older standalone web apps:
You log into UIs
This is externalised to an Authorization Server
An access token is issued with a fixed / short lifetime
Access tokens are used as API message credentials
The access token can potentially be sent to other components and used from there
When you logout:
You remove tokens from your app
You redirect to tell the Authorization Server the user is no longer logged into any UI
This doesn't invalidate access tokens
TOKEN STORAGE
Tokens should be stored in private memory or protected storage so that attackers cannot access them easily. Your app then removes tokens as part of the logout process so that they are no longer available for attackers to try to access.
THREATS
The OAuth Threat Model has a section on stolen tokens, where it recommends the above storage and to keep tokens short lived. The most common industry default for an access token is 60 minutes.
The main risk of a malicious party stealing a token is via cross site scripting. XSS risks are not related to logout. Security testing should be performed regularly to ensure that XSS risks are mitigated.
BALANCE BETWEEN SECURITY AND PERFORMANCE
It may be possible for the UI to tell the Authorization Server that a token is revoked. However, the API would then need to call the Authorization Server on every API request to check for token revocation. This would lead to poor performance.
API ARCHITECTURE
I always aim to use Claims Caching and introspection in OAuth secured APIs, since it gives the actual API best control, along with good extensibility and performance.
With this in place, if you really wanted to make access tokens non usable after logout, without ruining performance, your UI could perform these actions as part of the logout process:
Revoke the access token at the Authorization Server (if supported)
Call APIs to ask them to remove cached claims for the access token
Okta /introspect can tell you if active is true or false, you could check that on every request if you are not slamming the API https://developer.okta.com/docs/reference/api/oidc/#introspect
It's hard to get access to the token, that's probably a good reason why it's not per definition insecure.
However, providing a logout option is a good idea. OAuth2 has a 'revoke' feature to make sure that tokens are revoked:
https://www.rfc-editor.org/rfc/rfc7009
Not every server supports this.
The Setup
We’re building a PWA (progressive web app). The main components are the app shell (SPA) and the API. The REST API will supply the data needed for the app, while the SPA will handle the rest (as per Google recommendation).
The Problem
Authentication of the end-user seems problematic because the web browser needs to be accounted for. We want the user login to persist through closing down the browser.
We’ve done the research about the possible ways of going about it, however we’d like to ensure that we’re not going in the wrong direction.
Solutions we’ve considered
Session based authentication - the user sends username and password to /accounts/auth and receives a HTTP only cookie with the session ID. The session needs to be stored in a database or Redis. The issue with this option is that cookies are automatically sent by the browser therefore we need a CSRF protection in place. Using the Synchronizer Token Pattern a new token would be generated every time a state changing request has been made e.g. POST. This means that the application needs to supply a CSRF token with every request so that the PWA can send it via AJAX. We determined that it’s not ideal as the user can send multiple post requests in a quick succession making some of them fail and resulting in a bad user experience.
We could also use this method without the CSRF by limiting the CORS policy to same domain and adding a header requirement which technically should stop all CSRF, however we're unsure how secure it would be.
JWT token based authentication - the user sends username and password to /accounts/auth and a new JWT token is issued. The JWT then needs to be stored in localstorage or a cookie. Using localstorage means that JWT is XSS vulnerable and if the token is stolen, an attacker can impersonate the user completely. Using cookies we will still have a CSRF issue to resolve. We considered a double submit cookie method but the CSRF would only refresh every time the JWT is reissued which creates a window for the attacker to find out what the CSRF is. It is not clear which method is best to use.
Session based authentication + JWT token authentication - the user sends username and password to /accounts/auth, a session is created, a HTTP only cookie is set in the browser and a JWT token is sent back to the user. The PWA can authenticate requests with the JWT and whenever the JWT expires the app calls /accounts/auth again to acquire a new one. The /accounts/auth endpoint would still need to be CSRF protected, however the impact of it on usability would be minimised.
There seems to be a large amount of articles claiming that localStorage is insecure and shouldn't be used so why are high profile organisations like Amazon still recommending it? https://github.com/aws/amazon-cognito-auth-js - this SDK uses localStorage to store the token.
You don't need to generate new CSRF token each time a client make a request. It's much easier to use a scheme like token = hash(id + secret + current_day). You only need to update it once a day, or even employ mixed scheme (if the token is invalid today, but is okay for the previous day, the server accepts the operation and returns new token in a predefined header for client to renew it). You may also use the cookie as an id, making the token totally stateless and much easier to check, no need to store them in the database.
Here is how I look at it.
JWT token authentication : with this approach, you can always use a time-bound token with its expiration set to say 2 hours or something?
Or another approach would also be to try and see how you could use some of the approaches the Credentials Management API suggests for example, auto-sign-in of users whenever they come back.
Stuff like 2-step verification with OTPs for instance; for very important features in your web app can be a choice. In this case basic stuff are tied to whichever one time authentication method you have.
Actually, you can also use user-defined pins or short codes (seen a lot in banking apps) to grant access to some features in your web app.
Hope this helps, or sparks some ideation.
I have been reading around using tokens for authentication. I, however, fail to understand how tokens (JWT) are different from cookies. Both will store the user info (as claims in tokens), have persistence defined and will be sent with each client request to the server.
Few questions that come to mind, in addition to the above -
Are JWT tokens not prone to Man in the Middle attack? If someone steals a token (on an unencrypted channel), can't they pose as the original user? (unless we add the user's IP etc in the claims)
I've read a few rants that cookies are not good for new-age mobile apps and tokens are the answer. Why?
Why are tokens considered more secure than cookies? What makes them more invulnerable to attacks?
Does a token needs to be issued by the server only, or one can receive a token from another OAuth provider and customize (add/remove claims) and reuse it?
Performance wise, cookies are 'bad' as they have a size limitation, that is why they just store the session ID (typically) with session data in server. This reduces cookie size. But JWT, the whole token needs to be sent, so if the token contains the session data as claims, then we'll be essentially sending this ever increasing token every time. If am getting that correct, isn't that bad performance of JWT as compared to Cookies?
Thanks
Are JWT tokens not prone to Man in the Middle attack?
Yes, you should use HTTPS to ensure that no one can see the JWT in the HTTP request headers. If someone gets the token, they can pose as the original user. The same thing is possible with cookies.
I've read a few rants that cookies are not good for new-age mobile apps and tokens are the answer. Why?
Most mobile apps don't use browsers to make HTTP requests. Browsers make dealing w/cookies seamless for web developers. For mobile developers, using JWT's can be less cumbersome than dealing w/cookies.
Why are tokens considered more secure than cookies? What makes them more invulnerable to attacks?
Tokens aren't necessarily more secure than cookies (a cookie could be signed, just like a JWT). The security benefits come from not being exposed to exploits which trick the browser into inadvertently using the cookies (CSRF attacks).
Does a token needs to be issued by the server only, or one can receive a token from another OAuth provider and customize (add/remove claims) and reuse it?
A JWT is signed with a secret that only the server/organization that generated it should know. So only servers that know the secret can verify the token is valid. While the server that generates the token doesn't have to be the same one that validates it, it doesn't make sense for you to customize and re-use someone else's token.
Reference