Normally Google Access token is valid for one hour but I want to set it to no expiry. How can I do that, please help
Google access tokens are only good for one hour this is Oauth2 standard and can not be changed. You will need to use a refresh token to request a new access token. No idea if that is possible with dialogflow you will likely have to request your user authenticate again after an hour.
OT: Thats an impressive app you are working on if your users will be using it beyond the access token limit.
According to [1], OAuth token maximum lifetime is 1 hour (3600 seconds) and it cannot be changed.
If your intention is that your application may continue working without having to "manually" recreate a new token, then you could try creating a session client that scopes to multiple requests, as described in the Best Practices Dialogflow reference [2]:
"To improve performance, you can use a single instance of a session client object for multiple requests. The session client reuses the same access token for as long as it is valid (typically one hour). Once it expires, the session client refreshes the access token automatically, so you don't need to recreate the session client to refresh your access token. Your request that also refreshes the access token can take an extra second or two".
Please, try this and let me know the results.
[1] https://cloud.google.com/iam/docs/creating-short-lived-service-account-credentials#sa-credentials-oauth
[2] https://cloud.google.com/dialogflow-enterprise/docs/best-practices
Related
I'm here because I wasn't satisfied with what I found on google.
I am generally building SPA's, so for me the process was simple: At succesful login generate a jwt and use it for every request I make from the client.
Someone told me that I should refresh that token and send back a new one for every request I make. Does this make sense for me to do? I mean, if someone is trying to hack me, sniffing the requests will give the hacker the same tokens I receive, so what's the catch?
I mean, what if I launch a request before another one is finished? Teoretically I would send the same token twice and one of the requests will be rejected.
How is this correctly handled? I'm sure there is more to this than what I could think myself.
It is a compromise between security and convenience.
No, you don't need to refresh the token on each request. But you definitely want your JWTs to expire at some point. This is to protect you from JWT theft where malicious user could use stolen access token to gain access to target resource indefinitely.
Here is what you can do to handle token expiration:
Implement a refresh token flow. You will issue an access JWT and a refresh JWT when authenticating. Once access JWT has expired you will use refresh JWT to obtain new access JWT.
Implement sliding expiration. After the half of the JWT validity time has expired you would issue a new JWT. An example of it can be found here. I would recommend to include a deadline to when a token can be expired. For example, initial token validity is for 20 minutes and deadline is 8 hours. After 8 hours of sliding expiration you will stop issuing new tokens.
I'm referencing another SO post that discusses using refresh tokens with JWT.
JWT (JSON Web Token) automatic prolongation of expiration
I have an application with a very common architecture where my clients (web and mobile) talk to a REST API which then talks to a service layer and data layer.
I understand JWT token authentication, but I am a little confused at how I should use refresh tokens.
I want my JWT authentication to have the following properties:
JWT Token has an expiration of 2 hours.
The token is refreshed every hour by the client.
If the user token is not refreshed (user is inactive and the app is not open) and expires, they will need to log in whenever they want to resume.
I see a lot of people claiming to make this a better experience using the concept of a refresh token, however, I don't see the benefit of this. It seems like an added complexity having to manage it.
My questions are the following:
If I WERE to use a refresh token, wouldn't it still be beneficial to have a long term expiration for good practice on that token as well?
If I WERE to use a refresh token, would that token be persisted with the userId and/or JWT token?
When I update my token every 1 hour, how does this work? Will I want to create an endpoint that takes in my JWT token or my refresh token? Will this update the expiration date of my original JWT token, or create a new token?
Is there the need for a refresh token given these details? It seems that If the user is just using a JWT token to grab a new token (per the link above) then the refresh token is obsolete.
Let me come to your questions a little later down the line and start by actually discussing the whole purpose of a refresh token.
So the situation is:
The user opens the app and provides his login credentials. Now, most probably the app is interacting with a REST backend service. REST is stateless, there isn't a way to authorize access to the APIs. Hence, so far in the discussion, there is no way to check if an authorized user is accessing the APIs or is just some random requests coming through.
Now to be able to solve this problem, we need a way to know that the requests are coming from an authorized user. So, what we did was to introduce something called an access token. So now once the user is authenticated successfully, he is issued an access token. This token is supposed to be a long and highly random token (to ensure that it can not be guessed). This is where the JWT comes into the picture. Now you may/may not want to store any user-specific details in a JWT token. Ideally, you would want to just store very simple, extremely non-sensitive details in the JWT. The manipulation of the JWT hash to retrieve other user's details (IDOR etc.) is taken care of by JWT (the library being used) itself.
So, for now, our problem with authorized access is solved.
Now we talk of an attack scenario. Let's say using all of the above user Alice, using the app, has the authorized access token and now her app can make requests to all the APIs and retrieve the data as per her authorization.
Assume that SOMEHOW Alice loses the Access Token or put another way, an adversary, Bob, gets access to Alice's access token. Now Bob, despite being unauthorized, can make requests to all the APIs that Alice was authorized to.
SOMETHING WE IDEALLY DON'T WANT.
Now the solution to this problem is :
Either detect that there is something of this sort happening.
Reduce the attack window itself.
Using just the access token alone, it is hard to achieve condition 1 above, because be it Alice or Bob, it's the same authorized token being used and hence requests form the two users are not distinguishable.
So we try achieving 2 above and hence we add an expiration to the validity of the access token, say the access token is valid for 't' (short-lived) time.
How does it help? Well, even if Bob has the access token, he can use it only while it is valid. As soon as it expires, he will have to retrieve it again. Now, of course, you could say that he can get it the same way he got it the first time. But then again there's nothing like 100% security!
The above approach still has a problem and in some cases an unacceptable one. When the access token expires, it would require the user to enter his login credentials and obtain an authorized access token again, which at least in case of mobile apps, is a bad (not acceptable) user experience.
Solution: This is where the refresh token comes in. It is again a random unpredictable token that is also issued to the app along with the access token in the first place. This refresh token is a very long-lived special token, which makes sure that as soon as the access token expires, it requests the server for a new access token, thus removing the need for the user to re-enter his login credentials to retrieve a new authorized access token, once an existing one has expired.
Now you may ask, Bob can have access to the refresh token as well, similar to the way he compromised the access token. YES. He can. However, now it becomes easy to identify such an incidence, which was not possible in the case of an access token alone, and take the necessary action to reduce the damage done.
How?
For every authenticated user (in case of a mobile app, generally), a one to one mapped refresh token and access token pair is issued to the app. So at any given point in time, for a single authenticated user, there will be only one access token corresponding to a refresh token. Now assume that if Bob has compromised the refresh token, he would be using it to generate an access token (because access token is the only thing which is authorized to access resources through the APIs). As soon as Bob (attacker) requests with the newly generated access token because Alice's (genuine user) access token is still valid, the server would see this as an anomaly, because for a single refresh token there can be only one authorized access token at a time. Identifying the anomaly, the server would destroy the refresh token in question and along with it all, it's associated access tokens will also get invalidated. Thus preventing any further access, genuine or malicious, to any authorization requiring resources.
The user, Alice, would be required to once again authenticate with her credentials and fetch a valid pair of a refresh and access tokens.
Of course, you could still argue that Bob could once again get access to both refresh and access tokens and repeat the entire story above, potentially leading to a DoS on Alice, the actual genuine customer, but then again there is nothing like 100% security.
Also as a good practice, the refresh token should have an expiry, although a pretty long one.
I believe for this scenario you could work with the access token alone, making
life easier for your clients but keeping the security benefits of a refresh token.
This is how it would work:
When your user logs in with credentials (username/password) you return a
short-lived JWT. You also create a db record where you store:
JWT id
user id
IP address
user agent
a valid flag (defaults to TRUE)
createdAt
updatedAt
Your client submits the JWT in every request. As long as the JWT hasn't expired,
it has access to the resources. If the JWT expired, you refresh it
behind the scenes and return both the resource and an additional X-JWT header
with the new JWT.
When the client receives a response with an X-JWT header, it discards the
old JWT and uses the new one for future requests.
How refreshing the JWT works on the server
Look for the matching db record using the JWT id.
Check if the valid flag is still true, otherwise reject.
Optionally, you can compare the request IP address and user agent against
the stored IP address and user agent, and decide to reject if something looks
fishy.
Optionally, you can check the db record's createdAt or updatedAt fields, and
decide not to refresh if too much time has passed.
Update the updatedAt field in the db record.
Return the new JWT (which is basically a copy of the expired JWT, but with an extended expiration time).
This design would also give you the option to revoke all tokens for a user (for
example, if the user loses his phone or updates his password).
Benefits:
Your client never has to check expiration times or make refresh token
requests, all it does is check for an X-JWT header on responses.
You can add custom refresh logic based on IP address, user agent, max-token
age, or a combination of those.
You can revoke some or all tokens for a user.
If I WERE to use a refresh token, wouldn't it still be beneficial to have a long term expiration for good practice on that token as well?
Refresh Tokens are long-lived, Access Tokens are short-lived.
If I WERE to use a refresh token, would that token be persisted with the userId and/or JWT token?
It would be persisted as a separate token on the client, alongside JWT but not inside JWT. UserID/UID can be stored inside the JWT token itself.
When I update my token every 1 hour, how does this work? Will I want to create an endpoint that takes in my JWT token or my refresh token? Will this update the expiration date of my original JWT token, or create a new token?
Yes, you need a separate service that issues and refreshes token. It won't update the expiration of the existing JWT Token. A token is simply JSON field-value pairs that are base64 encoded. So changing the data, changes the output. The token also has the issue date, which will at the very least change on every fresh issue (refresh). So every token will be unique and new. The old tokens will auto-expire, hence you need expiration on all Access Tokens, otherwise they will linger around forever.
The other answer here states that old tokens get destroyed when you issue a new token. That's simply not the case. Tokens cannot be destroyed. In fact, you can harvest hundreds of tokens by constantly contacting the auth server and asking for new fresh tokens using your Refresh Token. Each of those Access Tokens will be valid till their expiry. So expiry is imperative, and it should be short.
Is there really the need for a refresh token given these details? It seems that If the user is just using a JWT token to grab a new token (per the link above) then the refresh token is obsolete.
JWT tokens have client claims. For example is_manager:true claim on a JWT token might allow access to manager-level features. Now if you decide to demote the user from manager to contractor, that won't take effect immediately. The user may still be using the old token. Finally when that expires, he hits the auth server to refresh his token. The auth server issues a new token without the managerial claim and the user won't be able to access managerial features any more. This creates a window during which the user's claims are not in sync with the server. This again explains why Access Tokens should be short-lived so sync'ing can happen often.
Essentially you are updating the authorization checks every 15 minutes, instead of checking them on every single request (which is how typical session-based auth works). If you want real-time permissions instead of every-15-minute refreshes, then JWT may not be a good fit.
Question 1
We are currently using ADFS and OAuth (using Windows Server 2012 R2 with ADFS 3.0). Our test applications (both WPF and mobile apps) can successfully authenticate and get an Access Token and a Refresh Token. We can after that continue to use the Access Token until it expires and after that use the Refresh Token to get a new Access Token.
So far so good, but the problem is when the Refresh Token expires, we need to force the user to enter their credentials again. Our aim is to have the user to only enter their credentials once and then use a short lifetime for Access Token and a Persistent lifetime (or really really long) for Refresh Tokens.
According to some blog posts when using a Refresh Token you should get a new Access Token and sometimes also a new Refresh Token, but in our case we never get a new refresh token, so that one eventually expires.
Is this even possible using ADFS 3.0 and OAuth to have a persistent Refresh Token? or get new refresh tokens from time to time so that the user doesn't have to enter their credentials again? or is it possible to have a really long lifetime for refresh tokens.
Question 2
There is also a lot of different properties you can set in ADFS that we are not sure of
TokenLifetime - This is the access token lifetime? what is maximum value?
SsoTokenLifetime - This is the refresh token lifetime? what is maximum value?
PersistentSsoLifetimeMins - what is this?
PersistentSsoEnabled - I guess should be set to true to have refresh tokens working
This post describes a semi-official answer. Here's an example of setting the required values -
Set-AdfsRelyingPartyTrust -TargetName "RPT Name" -IssueOAuthRefreshTokensTo AllDevices
Set-AdfsRelyingPartyTrust -TargetName "RPT Name" -TokenLifetime 10
Set-AdfsProperties -SSOLifetime 480
For the specified RPT, this would issue access tokens with a lifetime of 10 minutes and refresh tokens to all clients with a lifetime of 8 hours.
The only semi-official guidance I have been able to dig up is this slideset:
http://www.oxfordcomputergroup.com/wp-content/uploads/Access-the-future-Alex-Simons.pdf
which states:
Configurable Refresh token support
Lifetime:
workplace joined device 7 days (PSSO lifetime)
Non-workplace joined device max. 24 hours.
Persistent refresh token support in ADFS sure would be nice, but it seems they see the feature mostly as a tie-in to their mobile device management offerings.
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.
i have to confess i've had this question for a very long time, never really understand.
say auth token is like a key to a safe, when it expires it's not usable anymore. now we're given a magic refresh token, which can be used to get another usable key, and another... until the magic key expires. so why not just set the expiration of the auth token as the same as refresh token? why bother at all?
what's the valid reason for it, maybe a historical one? really want to know. thanks
I was reading an article the other day by Taiseer Joudeh and I find it very useful he said:
In my own opinion there are three main benefits to use refresh tokens which they are:
Updating access token content: as you know the access tokens are self contained tokens, they contain all the claims (Information) about the authenticated user once they are generated, now if we issue a long lived token (1 month for example) for a user named “Alex” and enrolled him in role “Users” then this information get contained on the token which the Authorization server generated. If you decided later on (2 days after he obtained the token) to add him to the “Admin” role then there is no way to update this information contained in the token generated, you need to ask him to re-authenticate him self again so the Authorization server add this information to this newly generated access token, and this not feasible on most of the cases. You might not be able to reach users who obtained long lived access tokens. So to overcome this issue we need to issue short lived access tokens (30 minutes for example) and use the refresh token to obtain new access token, once you obtain the new access token, the Authorization Server will be able to add new claim for user “Alex” which assigns him to “Admin” role once the new access token being generated
Revoking access from authenticated users: Once the user obtains long lived access token he’ll be able to access the server resources as long as his access token is not expired, there is no standard way to revoke access tokens unless the Authorization Server implements custom logic which forces you to store generated access token in database and do database checks with each request. But with refresh tokens, a system admin can revoke access by simply deleting the refresh token identifier from the database so once the system requests new access token using the deleted refresh token, the Authorization Server will reject this request because the refresh token is no longer available (we’ll come into this with more details).
No need to store or ask for username and password: Using refresh tokens allows you to ask the user for his username and password only one time once he authenticates for the first time, then Authorization Server can issue very long lived refresh token (1 year for example) and the user will stay logged in all this period unless system admin tries to revoke the refresh token. You can think of this as a way to do offline access to server resources, this can be useful if you are building an API which will be consumed by front end application where it is not feasible to keep asking for username/password frequently.
I would like to add to this another perspective.
Stateless authentication without hitting the DB on each request
Let's suppose you want to create a stateless (no session) security mechanism that can do authentication of millions of users, without having to make a database call to do the authentication. With all the traffic your app is getting, saving a DB call on each request is worth a lot! And it needs to be stateless so it can be easily clustered and scaled up to hundreds or even thousands of servers.
With old-fashioned sessions, the user logs in, at which point we read their user info from the database. To avoid having to read it again and again we store it in a session (usually in memory or some clustered cache). We send the session ID to the client in a cookie, which is attached to all subsequent requests. On subsequent requests, we use the session ID to lookup the session, that in turn contains the user info.
Put the user info directly in the access token
But we don't want sessions. So instead of storing the user info in the session, let's just put it in an access token. We sign the token so no one can tamper with it and presto. We can authenticate requests without a session and without having to look up the user info from the DB for each request.
No session ... no way to ban users?
But not having a session has a big downside. What if this user is banned for example? In the old scenario we just remove his session. He then has to log in again, which he won't be able to do. Ban completed. But in the new scenario there is no session. So how can we ban him? We would have to ask him (very politely) to remove his access token. Check each incoming request against a ban list? Yes, would work, but now we again have to make that DB call we don't want.
Compromise with short-lived tokens
If we think it's acceptable that a user might still be able to use his account for, say, 10 minutes after being banned, we can create a situation that is a compromise between checking the DB every request and only on login. And that's where refresh tokens come in. They allow us to use a stateless mechanism with short-lived access tokens. We can't revoke these tokens as no database check is done for them. We only check their expiry date against the current time. But once they expire, the user will need to provide the refresh token to get a new access token. At this point we do check the DB and see that the user has been banned. So we deny the request for an access token and the ban takes effect.
The referenced answer (via #Anders) is helpful, It states:
In case of compromise, the time window it's valid for is limited, but
the tokens are used over SSL, so unlikely to be compromised.
I think the important part is that access tokens will often get logged (especially when used as a query parameter, which is helpful for JSONP), so it's best for them to be short-lived.
There are a few additional reasons, with large-scale implementations of OAuth 2.0 by service providers:
API servers can securely validate access tokens without DB lookups or RPC calls if it's okay to not worry about revocation. This can have strong performance benefits and lessen complexity for the API servers. Best if you're okay with a token revocation taking 30m-60m (or whatever the length of the access token is). Of course, the API servers could also keep an in-memory list of tokens revoked in the last hour too.
Since tokens can have multiple scopes with access to multiple different API services, having short-lived access tokens prevents a developer of API service for getting a lifelong access to a user's data on API service B. Compartmentalization is good for security.
Shortes possible answer:
Refresh tokens allow for scoped / different decay times of tokens. Actual resource tokens are short lived, while the refresh token can remain valid for years (mobile apps). This comes with better security (resource tokens don't have to be protected) and performance (only the refresh token API has to check validity against DB).
The following is an addition to the benefits of refresh tokens that are already mentioned.
Safety First!
Access tokens are short-lived. If someone steals an access token, he will have access to resources only until access token expires.
"...But what if a refresh token is stolen?"
If an attacker steals the refresh token, he can obtain an access token. For this reason, it it recommended that a new refresh token is issued each time a new access token is obtained. If the same refresh token is used twice, it probably means that the refresh token has been stolen.
When the refresh token changes after each use, if the authorization
server ever detects a refresh token was used twice, it means it has
likely been copied and is being used by an attacker, and the
authorization server can revoke all access tokens and refresh tokens
associated with it immediately.
https://www.oauth.com/oauth2-servers/making-authenticated-requests/refreshing-an-access-token/
Of course, this is just another layer of security. The attacker can still have time to obtain access tokens, until the refresh token is used a second time (either by the attacker or the real user).
Always keep in mind that the refresh token must be stored as securely as possible.