I have a React Native application with JWT authentication access to my backend.
When the user authenticates the backend returns an accessToken and a refreshToken the idea is, that both tokens are stored in AsyncStorage along with the expirationTime stored for both tokens.
Right now the implementation is so there is a setTimeout function that checks if the token is about to expire and uses the refreshToken to update the accessToken.
This made me wonder how much of a security upgrade it is using refreshTokens.
If both are stored in AsyncStorage (on the client), both could be accessed, what is the point of having the refresh token?
If an attacker got access to the client storage, they could simply update the access token with the refresh token?
Related
I need to know that if that possible to refresh the firebase access token from back-end using node.js. I can get the token from front end and I need to refresh it and verify if the token is expired.
condition : if the token expired then need to refresh it in the back-end. but the token is generating from front end.
You need the Refresh Token to get a new ID Token (Access Token). If you are using the Firebase Auth Client SDK, then it'll do all of this.
// This returns existing token if valid
// else it'll refresh the token and return an new one
const token = await auth.currentUser.getIdToken()
In case you still need to get new token in your backend server, then you can use Firebase Auth REST API.
Again, you'll need to store the refresh token in a secure place and I won't recommend doing this unless it's just for testing or you don't have any other way.
I used Nodejs Express and ejs and passprot jwt.
I saved jwt token in the cookie by httpOnly the attribute.
And before the page is rendered,router.get('/',isauth.verifyToken(), adminController.checkUser);
,check if the token is valid.
If the token is not valid, redirect it to the login page.
exports.verifyToken = ()=>{
return passport.authenticate('cookie', { session: false, failureRedirect: '/users/login' });
}
Now, I want to use not only the access token but also the refresh token.
where should I save the refresh token?.
In my opinion, saving both access token and refresh token in cookies is not the answer.
Is it right to store refresh token in local storage?.
If local storage is correct, where should the logic of refreshing token?
If you have one backend that authenticates, issues tokens, and then consumes them, then there's no need to issue a separate refresh token. You can just rely on the access token. In fact, in such a setup, you're using an HTTP session, so you don't even need a JWT. If you have a separate authorization service that issues tokens, then it's best to store refresh tokens in your backend - in the service that will eventually call the authorization service to get new tokens.
In any way, don't store refresh tokens in the local storage. It's not safe to keep tokens there as they are vulnerable to XSS attacks.
I saved my jwt access token in react memory using useContext and useState. However, the access token gets cleared on page reload which is normal. But to keep user still signed into the site even when page reloads, I saved the user's name and id in local storage. However, to make a post for instance, user needs his access token.
So, I set up the access token to be 1minute and setup a refresh token route which generates another access token. I used axios intercepotor and useEffect to call the refresh token route whenever user wants to make a post. This saves the newly generated access token to the header and the user could make a post because the access token is present.
Also, before a refresh token is used to generate a new access token, the refresh token must be found in the redis database. Once it is confirmed that the refresh token is in the redis database, a new access token can be generated.
So, if this refresh token gets compromised, I can easily locate it in the redis database and delete it. Once it is no longer there in the redis database, it can't be used to generate a new access token. And the access token expires in 1 minute which makes it very useless quickly without access to the refresh token.
I wanted to know if this method is quite safe? I know that it may not be all that safe but do you think it is better than storing the access token in localstorage or cookie directly?
I'm building mobile and a web app. Both apps will be talking to a node server. I am using JWT for authentications.
Currently, I have the following code to generate an access token:
const token = jwt.sign({ user: body }, "top_secret");
I have some questions about access and refresh tokens:
How to create a refresh token?
What do refresh token look like?
Can I create a refresh token - similar to the way I'm creating an access token?
Is the refresh token only used to generate a new access token?
Can the refresh token be used as an access token?
How do you invalidate an access token
How do you invalidate a refresh token? Examples I've seen used databases to store refresh tokens. The refresh tokens are deleted when you want to invalidate an access token. If the refresh token would be stored in the database on the user model for access, correct? It seems like it should be encrypted in this case
When the user logs into my application, do I send both access token and refresh token? I read somewhere (can't remember where) that it's not good practice to send an access token and refresh token.
If its bad practice to send both access and refresh tokens, when do you send a refresh to the client? Should there be an endpoint where the clients request an access token?
What's a good expiry time for access tokens and refresh tokens?
Please note that in typical OAuth2 scenarios, the server issuing tokens (authorization server) and the API server consuming access tokens (resource server) are not the same. See also: Oauth2 roles.
To answer your questions:
How to create a refresh token?
You generate a string of sufficient entropy on the server and use it as a primary key to a database record in the authorization server. See refresh token syntax.
What do refresh token look like?
From https://www.rfc-editor.org/rfc/rfc6749#section-1.5,
A refresh token is a string representing the authorization granted to the client
by the resource owner.
The string is usually opaque to the client.
Can I create a refresh token - similar to the way I'm creating an access token?
You can, but refresh tokens are typically not structured tokens (like JWT) since they're consumed by the same server that issued them.
Is the refresh token only used to generate a new access token?
yes
Can the refresh token be used as an access token?
no
How do you invalidate an access token
Unless you're using introspection tokens, there's not a good way to invalidate them. Just keep their lifetime short.
How do you invalidate a refresh token? Examples I've seen used databases to store refresh tokens. The refresh tokens are deleted when you want to invalidate an access token. If the refresh token would be stored in the database on the user model for access, correct? It seems like it should be encrypted in this case
Delete if from the authorization server store. If the refresh token cannot be found on the server, it cannot be used to refresh an access token. A refresh token is typically just a primary key to a database record holding data about the client, user and expiration of the refresh token. While you don't want to leak your refresh token, it typically does require the client using them to present client credentials to use it.
When the user logs into my application, do I send both access token and refresh token? I read somewhere (can't remember where) that it's not good practice to send an access token and refresh token.
The user signs in at the authorization server. It returns an access token and refresh token (if your client is confidential) to the client. The client uses the access token alone to access your data on the resource server.
If its bad practice to send both access and refresh tokens, when do you send a refresh to the client? Should there be an endpoint where the clients request an access token?
Your client uses the refresh token in a call to the authorization server to get a new access token. So your client sends only the access token to the resource server and only the refresh token to the authorization server.
Whats a good expiry time for access tokens and refresh tokens?
That depends on your threat model. When your refresh token expires, the user is forced to authenticate again. Some products use refresh tokens that never expire, others use refresh tokens that are only valid for hours or days.
Last couple of days, i spent on an issue that how could i secure my jwt access token at client side (browser). Some blogs say that Local / Session storage is not secure to store the token. I moved to store the token in ngrx store but there is another issue that when user refresh the page, he/she must re-login to get the token again. Third option is cookie, a secure and http-only cookie.
Where to store my jwt token to secure it?
Note: In backend, a spring boot api is running which sends a token on successful login.