I'm building an electron desktop app, and in the app it will call the remote API with JWT token. However, where should I persist this JWT token safely without the threats like XSS, CSRF, man in the middle attack etc... and cannot be accessible by other applications
I've tried using node-keytar package, which uses an encryption key derived from the user’s login.
But according to this issue(https://github.com/atom/node-keytar/issues/88), the credential(JWT in our scenario) can still be compromised if the user's environment got a malware installed.
The code of node-keytar is fairly easy, here's the add secret
keytar.addPassword('KeytarTest', 'AccountName', 'secret');
and here's the get secret
const secret = keytar.getPassword('KeytarTest', 'AccountName');
console.log(secret); // "supersecret"
I'm thinking about just storing JWT into the memory might be the safest way, but will require user to re-login and get JWT token everytime they reopen the electron desktop app.
Any suggestions or thoughts are welcomed. Thanks!
In many use cases involving JWT, you would not need to necessarily do any additional encryption/obfuscation of the JWT before you send it to the API, because:
When you send the JWT to the API, you would be doing so via SSL or HTTPS, which encrypts the entire payload. This in theory would eliminate most chances of man-in-the-middle attacks.
Even if someone managed to sniff your JWT token, they would lack the server's key which is required to unlock it. Also, even if they managed to unlock the JWT, it would be almost impossible to alter its contents without also altering the checksum, which is contained within the JWT itself. This eliminates the chance of injection attacks by inserting something into the JWT.
So in general, the JWT pattern is a way of pushing server side session state outside of the application. And it does it in such a way that this state is protected from tampering on the outside. If it were possible to easily tamper with a JWT on the outside, the entire pattern would fall apart.
Related
So my question is about asymmetrically signed JWT tokens. How is it ensured that the signature can't be replicated on JWT tokens? If someone captures the JWT, what prevents him from reusing the same JWT over and over again without being properly authorized? I believe JWTs can have an expiration date, but it doesn't solve the issue since expiration date for most apps are relatively long in order to provide a good user experience. Most simplistic but a naive solution I can think of is having a nonce attached to the user starting from 0 and incrementing every time the jwt is used, and the request is processed.
Preventing replication of the signature of the JWT relies on you storing the key correctly that signed the JWT, either in a secure storage or some other safe place, reuse is a different story.
Now, for a start, I would also be worried if an attacker can easily steal your JWT, which almost implies that you don't use HTTPS/SSL, but sure, let's assume we are running a scenario where someone has exploited your SSL.
JWT's themselves are nothing more than ways of authentication a client, almost similar to how an API key works. It's pretty much a grant that that client can access some resource using that token. It doesn't hold any security value in that regard, other than at some point that client authenticated itself using the correct credentials.
So if it's stolen, you have a problem. This is where the lifetime of the tokens comes in to play. Tokens can expire very quickly, causing the attacker to only be able to access resources for a short while, but still, they did have access to a resource they shouldn't have access to.
In that regard, you can try to mitigate the attack using, like you mentioned, a nonce. Just don't forget to protect that nonce by a key that is related to the identity or session of the JWT. Alternatively you can add an HOTP or TOTP, or some unique signature to the request. This comes at a cost of you having to create extra logic at both your client and server.
So summarised, JWT's themselves don't really provide security, they provide authentication. Generally speaking JWT's are secure if using contemporary security measures such as SSL. If you really want to add additional security to the request, you are left to implement additional logic, such as OTP's or signatures by implementing more logic at the client and server.
Somehow implementing stateless authentication always brings me headaches.
This time it concerns silent auth vs refresh tokens.
Using refresh tokens seems discouraged, however there are certain arguments I don't really get.
If you use an http only cookie to store your refresh token, what exactly is the danger?
Attackers cannot get access the cookie with Javascript and if you use SSL (which you should), I really don't understand the problem.
The resources I read always say "you should not store sensitive data in the client". Seems like an automatic, but that is implicitly impossible if you want to eliminate the need for server session state. Neither do I really understand why, since no resource ever explains how it would be cracked (and I really wonder if anybody really knows).
The reason why I have this question is because using a refresh token offers me more than just authentication.
If a user for example loses his / her device, removing the refresh token will just invalidate all access tokens over all devices (not only browser), which seems like something a user wants to do.
After all, it makes sense that when you lose a device, you need to take action to protect your data.
So the argument "if the attacker gets access to the refresh token, he can infinitely refresh your token" sounds like another argument I don't get. The attacker should not get the refresh token. How would he ever get it? It's the same as saying "if the attacker gets hold of the code of your bank card, he has infinite access to you money". Well if you lose your bank card, you call card stop; likewise if you lose your refresh token, you would delete it to invalidate all access tokens. So how is this an argument?
Can you clarify why I cannot just store my refresh token in an http-only cookie, and how a silent authentication flow improves on this?
Edit:
Note that I read a few other articles that advise to store jwt in the browser by sending the encrypted jwt signature in an http-only cookie. These articles received a lot of upvotes, so that is suddenly okay. It makes zero sense to me.
Edit on comment:
The architecture is very simple:
React / Redux SPA with REST api in the backend
Need for social login through Google, LinkedIn, Github
Need to refresh the token without needed user interaction
Access my own api resources (preferably with jwt)
Ability to revoke refresh token
I don't know why it seems complex (lol).
Refresh tokens are widely used in:
Server side web apps, where they are stored in an HTTP only cookie, as you suggest
Desktop and mobile apps, where they can also be stored in OS secure storage
Refresh tokens should not be infinitely renewable and often represent the user session time - eg:
Refresh token / User session lifetime = 12 hours
Access token / API message credential lifetime = 60 mins
The concern for SPAs in the above article is that there is no real secure storage in the browser - though you are not intending to use browser storage - so no problems there.
One risk is that users can maybe get the secure cookie and replay it to an API via browser developer tools:
To mitigate this it is of course important to ensure that APIs have well engineered authorization - and that what the user can do with a token matches what they can do in the UI.
Another risk is CSRF where a malicious app in another browser tab sends the same cookie to your back end. So you'll need to protect against this.
Note that SPAs have their own token renewal solution based on Authorization Server cookies - I would prefer that option if using an SPA, rather than issuing your own cookie.
I am struggling to understand how JWT refresh tokens are safer than just using normal JWT access tokens with a long lifespan. I understand that by keeping the lifespan of JWT access tokens short, it limits the window of opportunity for attackers to abuse it. This assumes that the SSL layer of HTTPS has somehow been bypassed by the attacker in order to gain the JWT access token in the first place.
How do JWT refresh tokens solve this problem exactly? Once the access token expires, you would have to transfer the refresh token, which can also be hijacked if we assume that HTTPS is not secure enough. If the attacker gains control of the refresh token, then he now has access to a large supply of access tokens since refresh tokens typically have a long lifespan. By extension we could also say that the initial username/password authentication can be stolen if the HTTPS protocol is compromised.
Since the refresh token must be kept in the frontend (I am building a Angular/Spring boot application), we must take extra care that the refresh token can not be stolen client side as well. LocalStorage is clearly unsuitable to store the refresh token since it is not meant to be a secure storage. They are also unsuitable to be sent every request since they would be stolen together with the access token otherwise, which defeats the purpose of having short lifespan access tokens in the first place. Where should one store the refresh token?
If I wish to provide remember-me functionality at the loginpage, can I simply set the refresh token with an infinite lifespan?
I already went through several well written answers from the following links (and more):
What if JWT is stolen?
SPA best practices for authentication and session management
https://security.stackexchange.com/questions/119371/is-refreshing-an-expired-jwt-token-a-good-strategy
But I am left unsatisfied regarding these 3 questions.
I shall attempt to answer all the points in your question
Do not use JWT refresh tokens. Use Opaque refresh tokens. Typically, JWTs are to have very short life times. The reason for this is that revoking them may not be possible if you do not have blacklisting
You can store refresh tokens in HttpOnly, secure cookies. If you want to avoid CSRF and XSS, then you can split the access token and store half in cookies, and other half in localstorage
If you assume that https is compromised (which is actually possible), the best defence here is to have measures in place to detect stolen refresh tokens. You can do do by implementing rotating refresh tokens. This can also be used to implement remember me functionality quite easily and with the highest level of security.
In general, this topic is quite complex and it would be impossible for me to explain everything here. So here is a blog post I like that explain everything todo with session security. They also have an open source library called SuperTokens you can use that is by far the most secure implementation I have seen. They have it in various tech stacks, and can also implement one for your tech stack.
You've already received an answer and have selected it, but I thought I'd add another perspective.
I'll start by pointing out a bit of myth with one of your assumptions:
LocalStorage is clearly unsuitable to store the refresh token since it
is not meant to be a secure storage.
I'm sure some will disagree with me on this, but to me LocalStorage is just as secure as Cookie storage, if not more.
Cookies are susceptible to CSRF attacks, while LocalStorage not so much. And both LocalStorage and Cookies are susceptible to XSS attacks (even httpOnly cookies, since injected code could perform any operation withCredentials).
So from that perspective, Cookies offer a greater attack surface than LocalStorage.
Therefor I don't see any problem in storing access NOR refresh tokens in LocalStorage from purely a security perspective.
Beyond the security concern, you may need to store them in LocalStorage (or a non-Cookie store) depending on the platform(s) you deploy to, ex: some mobile frameworks don't support Cookies.
Conversely, if you plan to run a JS Web app that does server-side rendering, you may need Cookies since typically the server process will not have access to LocalStorage.
So the issue is not entirely one of security.
As for the main gist of your question, which I understood as:
If access tokens are susceptible to attacks, what makes refresh tokens helpful, as they too must be susceptible to the same attacks?
You're right. Both access tokens and refresh tokens can be compromised. The question is... what can your server do about it once it finds out?
The idea of access tokens and refresh tokens is that access tokens are short lived and refresh tokens are long lived.
Personally, I see little use in refresh tokens unless you're using JWTs as your access token, which is what you eluded to in your post.
As you probably know, JWTs are stateless (albeit you can implement white/black lists which would make them stateful, but that sort of defeats the purpose). Therefor there is nothing the server can do to disable a stateless JWT.
Due to this fact, some consider it risky to have long expirations on JWTs because they can't easily be disabled if compromised. I agree with this.
So to get the "best of both" worlds, one can use short-expiry JWTs (10 minutes or so) with long-expiry refresh tokens (many OAuth implementations never expire the refresh tokens).
This strategy gives your server some control back by allowing it to deny issuing new refresh tokens, thereby denying new access tokens, while also benefiting from some of the selling points of JWTs.
I have implemented JWT based security in a test Core Web API REST project, it is working fine but I am not sure that I see the benefit of this. The web says JWT is good because it's lightweight and can be used to verify that the source of data but in my implementation:
The client first provides a username and password to authenticate
If user + pwd is ok the a token is returned and every subsequent call to the api uses that jwt token (instead of the username and password) to authenticate.
This is fine but why not just use the username + password on every call to the api (and skip the complication of managing the token)?
In fact in my case there's additional complications because I now have to factor in an expiry date (of the token) that resides outside of my system.
Can someone explain what I'm missing here?
One of the main benefits and motivations for using JWT is that it allows your server side application to push all session state information outside of the application. That is, in a theoretical limit, a JWT implementation is actually stateless.
To directly answer your question, we can compare the workflows for what happens when username/password is submitted in every request versus submitting a JWT.
First, a JWT contains a claims section, which is typically written by the issuer of the token, i.e. the server side application. One of the fields is called exp, and contains the expiry time of the token. One property of JWT is that it is not possible for the user to tamper with them. This is enforced via a checksum, which would change if any part of the JWT changes. Taken together, this means that the user cannot alter the expiry time (or any other claim), and the server can implicitly trust this time. When the user submits a request with a JWT, in theory all the server has to do is just check exp to see if the token still be valid. That is, the session state actually lives outside the application, at least in theory.
In contrast, when the user submits a username/password each time, the server has no way of knowing what to do just based on that information. Rather, the server has to maintain the session state itself, and this can be costly both in terms of memory and performance.
In practice, JWT is never completely stateless, but, using a good implementation, it is usually possible to get the memory footprint very small, requiring only a bit of space in a cache (e.g. Redis or a similar tool).
I am developing a REST application with its own authentication and authorization mechanism. I want to use JSON Web Tokens for authentication. Is the following a valid and safe implementation?
A REST API will be developed to accept username and password and do the authentication. The HTTP method to be used is POST so that there is no caching. Also, there will be SSL for security at the time of transit
At the time of authentication, two JWTs will be created - access token and refresh token. Refresh token will have longer validity. Both the tokens will be written in cookies, so that they are sent in every subsequent requests
On every REST API call, the tokens will be retrieved from the HTTP header. If the access token is not expired, check the privileges of the user and allow access accordingly. If the access token is expired but the refresh token is valid, recreate new access token and refresh token with new expiry dates (do all necessary checks to ensure that the user rights to authenticate are not revoked) and sent back through Cookies
Provide a logout REST API that will reset the cookie and hence subsequent API calls will be rejected until login is done.
My understanding of refresh token here is:
Due to the presence of refresh token, we can keep shorter validity period for access token and check frequently (at the expiry of access token) that the user is still authorized to login.
Please correct me if I am wrong.
A REST API will be developed to accept username and password and do
the authentication. The HTTP method to be used is POST so that there
is no caching. Also, there will be SSL for security at the time of
transit
This is the way most do it, so you're good here.
At the time of authentication, two JWTs will be created - access token
and refresh token. Refresh token will have longer validity. Both the
tokens will be written in cookies so that they are sent in every
subsequent requests
Storing the tokens in cookies I not dangerous in itself, but if you somehow get you JWT module on your server to read them from there you vulnerable to CSRF attacks where any webpage can trigger a users browser to send a form + you sites cookie to your server unless you use CSRF tokens. So generally they are stored in localStorage and "manually" added to request headers every time.
On every REST API call, the tokens will be retrieved from the HTTP
header. If the access token is not expired, check the privileges of
the user and allow access accordingly. If the access token is expired
but the refresh token is valid, recreate new access token and refresh
token with new expiry dates (do all necessary checks to ensure that
the user rights to authenticate are not revoked) and sent back through
Cookies
Apart from the cookie dangers, it seems safe.
Provide a logout REST API that will reset the cookie and hence
subsequent API calls will be rejected until login is done.
You don't even need to make an API call, you can simply just purge the cookies or the localStorage object and make sure your client doesn't break on missing tokens.
The standard for the express-jwt module expects the tokens to be in its own "Authorization: Bearer [Token]" header, which I would strongly recommend over cookies. The localStorage API is available all the way back to IE8 so you should be good.
Edit:
First, it's important to know the difference between XSS and CSRF attacks since they're often believed to be the same thing.
XSS is when users get unsafe JS running on your domain in other users browsers when that happens neither JWT in localStorage or sessions and JWT in cookies are safe. With httpOnly flag on cookies, you can't directly access them, but the browser will still send them with AJAX requests to your server. If this happens you generally out of luck. To prevent this, make sure to escape all user input if it's sent to the browser.
If you load 3rd party JS with script tags or iframes this might compromise localStorage unless you are careful, but I haven't worked enough with this to help you here.
CSRF is only when other domains are trying to send normal HTML forms to your server by getting the browser to send cookies automatically. Frameworks prevent this by inserting unique random strings as hidden fields and checking them again when it's submitted. JWT's in localStorage is safe from this since each domain gets its own separate localStorage area.
But ultimately all this depends on if your service will be using one single domain, in which case httpOnly cookies will be plenty secure and easier to set up, but if you wanna spread your service out on multiple domains like api.domain.com + app.domain.com or add a native app you're forced to store you're JWTs in localStorage or some other native storage area.
Hope this helps!
I asked this question two years back and also accepted the answer. However, based on my experience and study in the last two years, I'd like to answer this just in case someone stumbles on this thread with the same question.
The approach mentioned in the question is similar to the "Resource Owner Password Credentials" grant type of OAuth 2.0. However, I think it is better to use the "Authorization Code Grant" type instead and Cookie to store the tokens instead of browser localStorage or sessionStorage. I have detailed my reasons, implementation points, security considerations and references in this StackOverlow answer.
Like OP I been using resource owner password grant.
I learned so much from Saptarshi Basu's other answer in a different post I think anyone looking into OAuth Code Flow should take a look at it, it has outlined a very solid approach to auth SPA and resource servers. It primarily relies on your backend(resource server) to handle authentication with the auth provider as a private client.
However, I will just add that people looking at implementing authentication with SPA should also consider OAuth Code Flow with PKCE. The main goal of PKCE is to allow public client such as SPA to authenticate directly with auth provider. All PKCE adds, is that when a SPA app initiates authentication, a hashed value is sent to the auth provider when the user is authenticated. And after user authenticate with the authorization provider, it redirects the user back to SPA with that hashed value as well as authorization code. Now, for the next part where the SPA calls auth provider to exchange code for tokens, instead of providing client secret, it has to provide the key that was originally used to create the hashed value. This mechanism guarantees the code cannot be used by someone who intercepted the code, and the SPA doesnt need to store a client secret like a server-side app does.
Now the only thing I'm not certain at this point is which is technically more secure, server-side authentication using standard Code Flow without PKCE or SPA authenticating directly using PKCE? Most resources I could find online currently describes and recommends the latter . However I feel that letting a private server side client handle authentication (as Saptarshi Basu described) might still be more secure. I would love to hear his opinion on this as well.
My understanding of refresh token here is:
Due to the presence of refresh token, we can keep shorter validity period for access token and check frequently (at the expiry of access token) that the user is still authorized to login.
Please correct me if I am wrong.
Assuming you're talking about using JWT as Bearer-token in OAuth (and I would strongly advice to follow the OAuth 2.0 protocol), that's right.
With an additional auth-time (timestamp of authentication) claim in your JWT, you could even drop the second token and sent your access- as a refresh-token (the auth-server could then issue a new access-token if token is valid & auth-time within allowed range)... but sure, it's also good to follow the standard ;)
Anyway, there are certain additional aspects (that tend to get difficult or are even against the fundamental ideas of JWT) you should consider before using JWTs as refresh-token, as this basically means you introduce long-living JWT:
do you need to have something like forced user logout/ token revocation by subject (e.g. if user got identified as fraudulent)?
do you need to have something like revocation of a specific token (e.g. if a user looses a device)?
...
Dependent on your use-case you should consider all the possible implications, long-living tokens have as they usually require you to introduce some kind of state on your server-side (e.g. to allow revocation/ blacklisting). Keep in mind the beauty and security of the JWT concept lies within JWTs being short-lived.