I have a access token which I call it A, and a refresh token.
so when I use the refresh token to refresh A, get a new access token which I call it B.
I have some questions:
1.older access token (A) is valid ? can I use it to request GOOGLE api?
2.if A is valid, how long will A expired?
3.if A is valid, the refresh token can refresh access token unlimited?
If you refresh OAuth token A, you cannot refresh it again. You need to use token B for the next refresh. Once you refresh token A to get token B, stop using token A.
Related
ex)
refresh token: A
acess Token : B
user acquistion : A, B
If B expires, use A to reissue B
So if the attacker steals A, doesn't he get B?
According to the rfc official documentation, I heard that the client has A and B, but I don't know if that's true.
I don't understand the mechanism of using the correct refresh token.
How should I shape the implementation direction?
I logged in and finished issuing refresh tokens and access tokens.
main question : When accessing a protected page, when the access token expires and there is a refresh token, I don't know how to use it. I don't know if it's true that the problem of being stolen arises.
In order to get the access token and refresh token, most of the time you're using your username and password. the idea of using tokens is to use as last as possible in your credentials on transit to avoid credentials stolen.
the different in this two token in the ability to revoke the token, while in access token you're not able to revoke the token (if the token steals the attacker can do anything), as the refresh token (a.k.a - your session) can be revoked, to if this token stolen you can revoke it and no new access token will be generate.
best practice is to generate short expiration for access token (for the case it will be steals), long period for refresh token - in order not use your credentials a lot.
My query is regarding supporting multi-device login for the same user at the same time using JWT tokens. I am using NestJS as my backend.
User table: userid, username, password(contains hashed password), name, refreshToken(contains hashed refresh token)
When the user does a /api/login call, on having a valid username and password, the access token and refresh token are generated using jwt passport library. The refresh token is hashed and stored in the refresh column of the user table for that particular user and the access token and the refresh token are sent to the client through the response.
During the /api/refresh call, the refresh token sent by the user is validated with the hashed refresh token that is present in the user table for that user and then, a new access token and a new refresh token are generated. The new refresh token is hashed and updated in the user table refreshToken column for that same user row.
This flow works perfectly for a user logged in with a single device. When the same user gets logged in using multiple devices at the same time, during login, the refresh token is updated in the refreshToken column of the user table for the same user row, which makes us lose an existing/valid refresh token for the same user.
Flow:
user 1 logs in using device 1 --> refreshToken column for user 1 is updated with a new refresh token
user 1 logs in using device 2 --> refreshToken column for user 1 is overwritten with a new refresh token and we lose the refresh token that was created for device 1
I would like to know what would be the best industrial practice to manage the JWT refresh flow for a user logged in with multiple devices at the same time?
The simplest way would be to keep the refresh tokens in a separate table. Usually, refresh tokens are kept separately from the user's account data, as the user can have more refresh tokens active at any given time. Whenever a refresh token is used you can find the concrete token and create a new one in its place.
By the way, there is no need to hash the refresh tokens kept in your database. They are unique to your system, they're not passwords.
The way I understand Access Token and Refresh tokens is as follows:
Authenticate to App
Receive (short lived) access token and (longer living) refresh token
requests resources from App with access token
If Access token expired request new Access Token with Refresh Token.
Refresh Token expires user must reauthenticate.
Lets imagine refresh token is valid for 30 days. On day 30 the user is in the middle of some business and his refresh token expires. Does he get automatically logged out? I haven't seen that happen...
So What is refreshing the refresh token without the user manually inputting credentials?
Every time the application asks for a new Access Token (step 4 in your list), it can also be given a new Refresh Token, with an even later expiry.
Effectively, the life time of the Refresh Token is the maximum idle time of the user's session.
I issue an access token along with a refresh token upon successful login. They are both saved in same site cookies in the browser. A custom middleware will put the token in Authorization header before the authentication process. This middleware will also check if the access token is expired, if it is it will try the refresh token, if validated it will save two new cookies(the new refresh token and new access token) and pass the new generated access token with the current request.
Is this how we are supposed to implement refresh tokens? If I want to blacklist a specific refresh token, should i save all refresh tokens in the database?
string auth = httpContext.Request.Cookies["AuthToken"];
if(string.IsNullOrEmpty(auth))
{
httpContext.Request.Headers.Add("Authorization", $"AuthorizationCookieNotFound");
return _next(httpContext); //That token wont be accepted i just
// put it there for the sake of demonstration
}
httpContext.Request.Headers.Add("Authorization", $"Bearer {auth}");
return _next(httpContext);
You have to be very careful while storing refresh tokens and they must be kept at some secret place otherwise you know the consequences.
I assume you are using "Aurhorization Code flow" here. So it's a good idea to store the refresh tokens in the db against the username and you can add an extra column e.g "IsRevoked" for status purpose and then you can blacklist/whitelist the tokens basked on the username and isrevoked status.
See this link about storing tokens.
Just a quick question and I haven't been able to find this answered anywhere.
If I have a user with a Refresh Token with scope x and I need to add scope y, will they be issued a new refresh token or do I keep their existing refresh token.
My expectation is that no new Refresh Token is generated, it is the access token which will have the new scope and I use the existing Refresh Token to get the new access token on the server.
Is my understanding correct here?