I'm kind of new to using google-oauth using passport. I've been trying to understand how it works but what i mostly don't understand is, where the access token and refresh token used in the googleStrategy?
Can we use the refresh token and the access tokens to implement the access token logic?
Related
I am currently attempting to implement auth into my API and am puzzled by the concept of refresh tokens. I understand they are for generating new access tokens upon their expiration, however I am unsure as to what payload they are meant to carry and how they are meant to be stored in the DB.
Several sources have implemented refresh tokens using the same payload as the access tokens (i.e a userId). Others have implemented a session system whereby a session object is serialized and checked upon validation.
My main confusion regards the validation and invalidation of refresh tokens. Are refresh tokens meant to be stored in the DB alongside the user, such that you can check that it is valid (and not being reused)? If so, should it be deleted from the DB when a new refresh token is generated? If this is the case, how do you allow for multiple sessions across several clients? It seems wasteful to store all past refresh tokens or session objects in the DB, particularly if the expiration time of the access token is short.
Apologies for the somewhat rambling question. This topic is one I'm struggling to get a grip of so any help would be much appreciated.
First please understand the importance of JWT token , they are meant to verify the integrity of the user i.e. genuine user.
For this purpose access token are generated and verified at each request to check weather the authentic user is making that request and also these token have expiring time based on your requirement and to refresh them refresh token are used. now lets say your token have very short TTL and you make request to refresh your token with each request of refreshing these token your server has to access DB and refresh the token , if you have store serialized object in token then it would add another business logic to deserialize and check for the Userid.
therefore the you should store minimum information in these token access token as well as refresh token , and this refresh token you should store along side user with minimum information.
I understand the concept of JWT and the need for a refresh token.
As far as I understand, it's to add an additional layer of security so even if the N number of access tokens generated from the fresh tokens are leaked, as long as you keep the refresh token in a safe place (a separate place) it's safe. I get that.
But what I don't understand is, why can't you just do the following?
A client authenticates
The server gives the client an access token.
After a while, the client's JWT expires. The client knows when it expires because it's baked into the token definition.
The client re-authenticates with the server.
The server re-issues a new unique access token.
Doesn't this solve the same problem of a more complex refresh token + access token pattern? I'm sure I'm missing some details. Are there use cases where this model doesn't work (or work)?
I'm having an identityServer with some clients and it works great. My problem is, when one of the admins changes the roles of a user, the clients need to sign up and sign in to get the new claims and roles.
My question is, is there is a away to let the roles get updated automatically after changing the roles, without getting signed out and in?
for any help i would be very thankful :)
You can set this flag to true in the client definition to reload the claims inside the access token when you refresh them
UpdateAccessTokenClaimsOnRefresh
Gets or sets a value indicating whether the access token (and its claims) should be updated on a refresh token request.
see https://docs.duendesoftware.com/identityserver/v5/reference/models/client/
For refresh tokens, I add some pictures from my training class that might give a better idea about refresh tokens (you ask for them using the offline_Access scope)
When you ask for that scope and give consent, then you will get an additional "refresh token"
And using the refresh token you can then ask for new access tokens.
The picture (Taken from my training class) shows how the sliding refresh token works:
You do ask for a new token (using the refresh token) when the access token is about to expire. The lifetime of the access token is shorter than the refresh token.
You either do that manually or you use some library like IdentityModel.AspNetCore to do it for you.
I'm building a react native app which uses the spotify web api. I'm using the authorization code flow to authorize a user. First I get a authorization code which can be used to obtain an access token and a refresh token. Everything works!
The problem is: an access token is only valid for a limited amount of time. That's where the refresh token comes in. I understand this concept, but I'm breaking my head about how to implement this.
Let's say a users opens the app, requests an access token and uses this for some time. Then, the user closes the app. After 15 minutes, the users opens the app again. The access token has now expired, so I need to request a new access token.
I've come op with several "solutions". Can someone point me to the correct solution?
Solution 1:
Every time the user opens the app, I request a new access token and use this. Problem: when the user uses the app longer than the valid time of the access token, I won't work anymore.
Solution 2:
I use the access token that's stored in the secure storage on every request. When a request comes back with 'access token invalid' (I don't know the exact error code but you guys know what I mean), I request a new access token with the stored refresh token, and then I send the previous command again (with the new access token). But my question here is: can I use some kind of "wrapper function" which checks the response of the request, and if the response is "access token invalid", it automatically requests a new access token and runs the previous request again.
I think certainly correct solution is solution 2,and i think its clear enough.
and for using solution 2 you need somthing like wrapper function,yes its intelligently.
so you should use interceptor:
what is interceptor ?
You can intercept requests or responses before they are handled by then or catch.
in link below there is a good example of implementing refresh token in axios interceptor:
https://gist.github.com/Godofbrowser/bf118322301af3fc334437c683887c5f
I agree that Solution 2 is the best, each time you do a request you can check to see if the Access Token has expired, and if it has then you can request a new Access Token using the Refresh Token as you mentioned and then make your request, in my own project I do this in a FormatRequestHeadersAsync method which calls a CheckAndRenewTokenAsync method where I perform the following check, here shown in C#:
if(AccessToken?.Refresh != null && (AccessToken.Expiration < DateTime.UtcNow))
{
AccessToken = await GetRefreshTokenAsync(
AccessToken.Refresh,
AccessToken.TokenType,
cancellationToken);
}
You can store the Access Token and the Refresh Token and then use something similar to this before you make each request to the API this will refresh your token and then you can store the new Access Token and the existing Refresh Token.
I am a fair way through implementing an actionscript OAuth library which I am initially testing with Google's Drive Api.
I know how you are supposed to refresh an access token using your refresh token but my question is how do I test it?
How do I make my access_token expire so that I test my code that catches the error, attempts a refresh and then re-loads the initial request? If I can only do this once a week (or however often they expire) it's going to take a while to get it right!
Thanks
If you're looking to test your code, you don't actually need to invalidate or expire the access token. Simply make a (say) Drive call with a null access token and you will receive the same 401 response that you would have got with an expired access token.
Well, judging by the lack of responses to this question I am assuming that there is no way to do this.
This page:
https://developers.google.com/youtube/v3/guides/authentication#installed-apps
describes how to revoke an access or refresh token by using this url:
https://accounts.google.com/o/oauth2/revoke?token={token}
but then says:
The specified token can be an access token or a refresh token. If the token is an access token and it has a corresponding refresh token, the refresh token is also revoked.
So if you just want to revoke an access token you aren't able to.
I think the only solution is to wait for the access token to expire (seems to take an hour) then go about testing your app.
I'll be very happy if anyone tells me a faster way to make the token expire.
I handle this testing by simply making note of an expired access_token. Then when I need to test how my app deals with an expired token I simply give the app that expired token to work with. This way, for example, I can test that requests with an expired token will fail as expected.
The easiest way of doing it is using the OAuth Playground 2.0
https://developers.google.com/oauthplayground/
In step 2 especially, you can try refreshing your access token with a refresh token.
Additionally, in the setting (the gear icon), you can set up your own OAuth Credentials to test it out for your own API project.
Im using nodemailer. When setting the options for the transporter object, you can specify an 'expires' time. There isn't any documentation I found on that option but I'm sure you can figure it out. :)
I haven't found a way to shorten the expiration time on an access token either.
In fact you can't even generate another refresh_token unless you revoke access. I don't think you can generate another refresh_token even if you let the access token expire, although I have to wait an hour to test this.
I did find out that if you send the refresh_token and the authorization token is still active, you just get the same live token back although the expiration time is reset.