Quick question, how long does a bearer token last in Social Tables before it expires and has to be refreshed? In other words, how often do we need to refresh the bearer token?
Our bearer tokens are valid for two weeks from the time issued.
Thanks.
Related
I am playing with GIS and the token I request only lasts for 3599 seconds, it looks like this:
{"access_token":"ya29.****","token_type":"Bearer","expires_in":3599,...
The token only lasts for 3599 seconds.
Is there any way that I can make it last longer?
I'm using the Javascript client to request the token in a browser like this:
tokenClient.requestAccessToken();
Thanks
This is an integral part of Oauth2. Access tokens are bearer tokens which means that they are valid to who ever has it but only for a limited amount of time.
The most common expiration is one hour. There are two ways to get a new one.
Ask the user to authorize the application again after the access token has expired.
Request offline access, in which case you will get a refresh token back. A refresh token can be used to request a new access token. (this can not be done with client side JavaScript only with server sided programming languages.)
I have been searching lately about refresh tokens and access tokens with rotation and something hit me.
Why not just use one token instead of access token and refresh token? Include in that token payload (claims) a validation date, and make the validation period very low ( just like access tokens ) and the expiration date very high ( just like refresh tokens ).
If the validation date exceeds the date on the server but did not expired, the server issues a new token and invalidate the old one ( by whatever mean like a blacklist of tokens etc just like when AT expires and new ones are issued using Refresh token) , and if the token expires then the server simply reject the request and ask for authorization ( just like when refresh tokens expires ).
If this approach works then why do we use 2 tokens which makes the dev process harder ?
I think you are forgetting something.
Refresh tokens are stored on the server. Access tokens are not. Access tokens are self contained. This is why they are referred to as bearer tokens. The bearer of the token is granted access.
Which means if an access token is stolen by a malicious party, they can be used as long it has not expired. Access tokens are considers safe because of their limited life span.
In order to use a refresh token in order to request a new access token. You need to have the client id, client secrete that was used to cerate it. You also need to be able to listen to one of the valid redirect uri's for the refresh token response.
I'm trying to get a token valid for a long time and I am not sure how to proceed.
I'm sending data to a Google Sheet on a daily basis so a 24h token doesn't allow me to have this automated.
Thanks
I have since found a way to make my script work. In the script, do not include the access token, ONLY the refresh token.
By having both, it prevented the refresh token of getting a new token and was simply using the expired token.
The generic way of obtaining tokens expiring longer than 24 hours is to get a refresh token. You can start by reading the instructions here:
Using OAuth 2.0 to Access Google APIs
Get Refresh Tokens
Refreshing Access Tokens
If I know that my auth provider sets refresh tokens to expire after twelve hours, and I have authenticated and my auth_time claim shows as 9AM today, can I safely assume that at 9PM tonight my refresh token will expire? Or are auth_time and refresh token issuance/expiration independent of one another?
It depends on the auth provider, but in some providers you can set difference expire times on the different tokens (id/access/refresh). Also some supports absolute or sliding expiration times.
Sample expire config options for IdentityServer can be found here for inspiration.
As you know, there are some good reasons for using token based authentication instead of session based.
In session based, of course there is a expiration time. So if user is not active for a while, his session get expired. But before expiring, if he send request to server, his time will be extended.
There is an awesome tutorial here about JWT. I have a question about expiration time for token. Imagine we set the expiration time to 100 seconds, then we sign the token. It doesn't matter user is active or not. After 100 seconds that token will not be valid anymore. This bothers the user. Is there any way to extend the time?
Is it a true approach, or maybe I have a mistake. Any idea?
If I understand the question correctly, it is fairly simple to alter the expiration of a JWT token during creation...
The "exp" (expiration time) claim identifies the expiration time on
or after which the JWT MUST NOT be accepted for processing. The
processing of the "exp" claim requires that the current date/time
MUST be before the expiration date/time listed in the "exp" claim.
More information can be found here https://www.rfc-editor.org/rfc/rfc7519#section-4.1.4
Basically the exp key takes a unix timestamp - set the timestamp to > 100 seconds from now and you will accomplish your goal.
To "refresh" the token your API needs a service that receives a valid, JWT and returns the same signed JWT with the updated expiration.
Silent refresh
There are 2 major problems that users of our JWT based app will still face:
Given our short expiry times on the JWTs, the user will be logged out every 15 minutes. This would be a fairly terrible experience. Ideally, we'd probably want our user to be logged in for a long time.
If a user closes their app and opens it again, they'll need to login again. Their session is not persisted because we're not saving the JWT token on the client anywhere.
To solve this problem, most JWT providers, provide a refresh token. A refresh token has 2 properties:
It can be used to make an API call (say, /refresh_token) to fetch a new JWT token before the previous JWT expires.
It can be safely persisted across sessions on the client!
Here a brilliant exhibition in HASURA BLOG--> https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/
You didn't give further information, but I'll assume you are going to use JWT for web-browser authentication.
you can save your JWT in a cookie with httpOnly and secure attribute and set cookie expiration time long enough(maybe 1 years) and inside of your JWT claims set exp property to a shorter time ( maybe 1 week or something else). now in every request the cookie will be sent to the server so you can check for expiration time.
something like this :
if(decodedJwt.exp < Date.now()){
//token is valid, do your stuff
}else {
//token expired, regenerate it and set it to the cookie
//also update the expire time of the cookie
}