In OnLogin, Access token is valid for 10 hours and Refresh token is valid for 45 days.
I want to generate a new tokens(Refresh +Access Token) after 9.59hours.
My Question:
What will happen to the refresh token.Will it ever expire as I am generating the tokens(Refresh + Access token) for every 10 hours?
What is the best approach? Should I be refreshing the token or generating a new token for every 10 hours.
What can be done if the rate limit of 5000 is crossed with in an hour. Please suggest any alternatives.
Any suggestions or comments
Nope. Refresh token lifespan is measured from when it gets created. If you create a new one via refresh it'll 'live' for 45 days. The allows you to hold on to the tokens and still be able to make a new access (and refresh) token even if you haven't used them for a long while.
Some folks choose to simply use the generate token call and use the clientID/Secret to constantly generate a new access token. But this is not as secure as using the access token to make calls until you get a response that it's expired, and then use the refresh token (and refresh token call) to get a new access / refresh pair. The minimizes the chances that your secret/clientID will ever get leaked.
Once you've exceeded 5000 / hour you're done for the hour. I'm curious what scenario you have that needs more calls than this.
This number can be raised for certain extraordinary circumstances (You're a giant customer with a big account) but that's between you and your customer service contact.
Related
I don't see a point in which you would with implemented refresh token rotation blacklisted tokens instead of keeping track of current ones.
If you are blacklisting tokens, you would get a lot of tokens blacklisted very fast. Let's assume your access token TTL is 5 minutes and your refresh is 7 days. If user is using your app for and hour, he would blacklist 12 tokens in that time. If you have great number of users, that would be a lot of blacklisted tokens.
Problem with that is also theft of refresh token. If someone managed to steal it, they can immediately exchange it for pair of new tokens, users active token (that is stolen) would be blacklisted and thief could just use your app normally from that point. How to solve that? Your user would provide blacklisted token on next request and would be logged out, he will log in again and start normally using app but so does the thief, since his token is valid, unless you invalidate his token somehow, but for that you need to keep track of current tokens.
Why just don't keep track of current client token? On every refresh request, you just check if provided token is current users token, if it is not put token value in database to "null". That why users will be forced to log in even if they stole your refresh token since current token must be valid to even check the database if it is same as current (because if refresh token is invalid or expired, you must logout user). Next time they log in, you would set new current refresh token in database and thief can't do nothing with stolen token.
Isn't this breaking stateless rule? It does, but in classic session you need to check database on every request, in this system you would check only when access token expires.
Plus, you don't need to keep track of possible of millions blacklisted tokens and you prevent from refresh token theft.
Only downside I see is that if someone actually steals your refresh token, and you never make any requests after that, they will be logged in until they log out or somebody sends bad request to refresh token endpoint that will "lock" your account.
When the user gets authenticated, AWS Cognito provides three tokens - idToken, accessToken, and refreshToken.
AWS Cognito configurations only allow a maximum of 24 hours expiry time for idToken, see below image.
Now if we look at apps like Facebook, they never expire user login automatically. But in our case, the user needs to log in every 24 hours once.
Question: How can we keep idToken alive forever using refreshToken or something else? Please also guide me in case I need to do it on the server-side, what best I can do to ensure all idTokens are refreshed in a timely manner.
You cannot keep an ID token forever. As you noticed yourself, the maximum validity time for an ID token is 24 hours. There is literally nothing you could do to change this configuration.
There might be a way around it, but you need to keep refreshing the ID token using the refresh token. The refresh token can be configured to expire after 10 years. All you have to do is to keep on using it every time you see that the ID token expired. If you are using an SDK it will normally do it for you. You just sing in once and the SDK will keep on refreshing the ID token.
Just keep in mind that you will get a new ID token (as well as an access token) each time you use the refresh token. It does not update the validity of the original token.
I'm running a website + native apps that communicate via HTTPS with my backend. The following requirements must be fulfilled:
Sliding session on the website. That means if the user interacted with the website within the last xx Minutes, he must not be logged out
Remember me on the website. When this is checked, the user must not be logged out (or after a very long time)
The user must not be logged out on the app
Access can be revoked, either by the user (currently logged in) or specific events (password changes).
What I currently have is the following: A refresh token endpoint generates a JWT when password hash and username match in the database. Every refresh token has a jti that is stored in the database, as well as expiration (for DB cleanup only), device_id and a revoked flag.
Another endpoint can be hit with the refresh token, which returns a JWT access token. The access token is valid for 15 minutes. The access token cannot be revoked.
My problems arise with requirement 1. I do not want the user to reauthenticate when he's interacting with the website. This means I need the refresh token. However, the refresh token must only be valid for e.g. last user interaction + xx Minutes. I cannot extend the access token with every request, as there is no way to blacklist access tokens. This would mean that a leaked access token is like a master key forever (as long as you constantly hit the api in 15-minute intervals). But I also do not know what the expiration for the request token could be.
The second problem is (2) with incognito modes or multiple devices. Assuming the user opens 20 private tabs and uses remember me on all of them. Then I have to store 20 tokens in the database. I could, of course, set a limit for type "web" to say 5 and "app" to 3 and remove the oldest last accessed one from the database (and therefore invalidate it). But this would log him out on the "main" browser if he opens 5 private tabs somewhere. It would also limit the number of phones to e.g. 2.
Different PCs/laptops would also generate many refresh tokens of type web. How would I best identify the corresponding device so access can be revoked, but I also do not store hundreds of refresh tokens over the application's lifetime? Best would be one refresh token per device (windows+firefox, iPhoneA, iPhoneB, windows2+firefox). But identifying desktop PC's is super hard.
What it comes down to is:
How can I store refresh tokens in the DB so they are identifiable to the end-user (e.g. Whatsapp webs "Safari started in New York last used at xxx-xxx-xxx"
How do I avoid having hundreds of tokens per user in the DB (as refresh token basically never expire, and the user can open as many private tabs as he likes without logging off)
How can I implement sliding windows with the refresh/access token pattern? So no unlimited refresh token on the client-side, but also no logoff after the access token expires as long as there is any usage. I could have it in the session storage, but then it still clutters my database and shows to the user as "currently logged in" (which displays all refresh tokens) as it's basically still valid.
Sliding session on the website. That means if the user interacted with the website within the last xx Minutes, he must not be logged out
To solve this problem you can use a refresh token, i.e when the user login for the first time, the application will return a access token (JWT format), with an expiration date set to the amount that you want.
When the user will browse the application, your backend will return a X-Refresh-Token header valid for your xx amount of time (i.e you'll need to return this header for each backend call).
If the acess token is expired (the backend will read the access token used, and perform check on expiration date token field), the backend will return a 401 Unauthorized error,
and your client must call the authentication endpoint, providing the last refresh token stored, to issue a new access token.
With this implementation your requirement #1 is satisfied.
Remember me on the website. When this is checked, the user must not be logged out (or after a very long time)
To solve this one, you'll just need to generate a long lived access token (i.e with an expiration date set to the amount of time you want).
The user must not be logged out on the app
I don't understand this one
Access can be revoked, either by the user (currently logged in) or specific events (password changes).
This one is really tricky. Since backend is stateless, revoking access token is a really complex topic.
Hopefully a lot of pattern existing to solve this one, we just need to discuss about it.
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
I want to extend my existing token.
I make a facebook authentication with server side call and I got fb access_token with 60 days time.
Then next day I make a call, https://graph.facebook.com/oauth/access_token?client_id=APP_ID&client_secret=APP_SECRET&grant_type=fb_exchange_token&fb_exchange_token=EXISTING_ACCESS_TOKEN
In FB documentation https://developers.facebook.com/roadmap/offline-access-removal/ they says,
our platform will only extend the expiration time once per day, so even if a user revists your site multiple times a day, the token will be extended the first time requested
But I got same access_token without time extended.
How to extend my existing token?
The returned access_token will have a fresh long-lived expiration time, however, the access_token itself may or may not be the same as the previously granted long-lived access_token.”
You told returned token will have fresh long-lived expiration time.
For example EXISTING_ACCESS_TOKEN - valid token with 50 days validity
I make a call with query https://graph.facebook.com/oauth/access_token?client_id=APP_ID&client_secret=APP_SECRET&grant_type=fb_exchange_token&fb_exchange_token=EXISTING_ACCESS_TOKEN.
In that response facebook returned same token and same 50 days time validity. After 50 days this token will be expired.
My question is how to extend my expiration time? Or What is wrong with this query?
But I got same access_token without time extended.
Off course you do, because that's exactly what's descriped under "Scenario 4" here: https://developers.facebook.com/roadmap/offline-access-removal/#extend_token
It's all in there, you just have to read it ;-)
If you pass an access_token that had a long-lived expiration time, the endpoint will simply pass that same access_token back to you without altering or extending the expiration time.
[...]
If you would like to refresh a still valid long-lived access_token, you will have to get a new short-lived user access_token first and then call the same endpoint below.