Keycloak refresh token lifetime is 1800 seconds:
"refresh_expires_in": 1800
How to specify different expiration time? In Keycloak admin UI, only access token lifespan can be specified:
As pointed out in the comments by #Kuba Šimonovský the accepted answer is missing other important factors:
Actually, it is much much much more complicated.
TL;DR One can infer that the refresh token lifespan will be equal to the smallest value among (SSO Session Idle, Client Session Idle, SSO Session Max, and Client Session Max).
After having spent some time looking into this, and now looking back at this thread, I feel that the previous answers felt short to explain in detail what is going on (one might even argue that they are wrong actually).
Let us assume for now that we only have SSO Session Idle and SSO Session Max:
and SSO Session Max > SSO Session Idle in this case the refresh token lifetime is the same as SSO Session Idle. Why? because if the application is idle for SSO Session Idle time the user gets logout and that is why the refresh token is bound to that value. Whenever the application requests a new token, both the refresh token lifetime and SSO Session Idle countdown values will be reset again;
and SSO Session Max <= SSO Session Idle then the refresh token lifetime will be the same as SSO Session Max. Why? because regardless of what the user does (i.e., idle or not) the user gets logout after SSO Session Max time, and thus why the refresh token is bound to that value.
From here we conclude that the refresh token lifespan is bound to the lowest of the two values SSO Session Idle and SSO Session Max.
Both those values are related to Single Sign-ON (SSO). We still need to consider the values of the Client Session Idle and Client Session Max fields of the realm settings, which when NOT set are the same as SSO Session Idle and SSO Session Max, respectively.
If those values are set, in the context of the refresh token, they will override the values from SSO Session Idle and SSO Session Max, BUT only if they are lower than the values from SSO Session Idle and SSO Session Max.
Let us see the following examples: SSO Session Idle = 1800 seconds, SSO Session Max = 10 hours and:
Client Session Idle = 600 seconds and Client Session Max = 1 hour. In this case, the refresh token lifespan is the same as Client Session Idle;
Client Session Idle = 600 seconds and Client Session Max = 60 seconds. In this case, the refresh token lifespan is the same as Client Session Max.
Client Session Idle = 1 day and Client Session Max = 10 Days. In this case, the refresh token lifespan is the same as SSO Session Idle;
So in short you can infer that refresh token lifespan will be equal to the smallest value between (SSO Session Idle, Client Session Idle, SSO Session Max, and Client Session Max).
So the claim from previous answers that you can simply use the Client Session Max to control the refresh token lifespan is FALSE. One just needs to look at the previous examples 1) and 3).
Finally, the fields Client Session Idle and Client Session Max from the realm settings can be overwritten by the Client Session Idle and Client Session Max in the clients themselves, which will affect the refresh token lifespan for that client in particular.
The same logic applies but instead of considering the values Client Session Idle and Client Session Max from the realm settings one needs to consider those from the client advance settings.
The refresh token lifetime is controlled by the SSO Session Idle Setting. 30 minutes = 30 * 60 = 1800 seconds (the refresh_expires_in value)
In v11.0.3, under the advanced settings for the client, there are no SSO Session Idle settings (not sure if these have just been renamed, moved, or are a realm setting available elsewhere in the admin interface), so starting with default client settings, you can specify Client Session Max to control refresh token lifetime without needing to change the other duration settings (Access Token Lifetime continues as you would expect). Evidence: adjusting settings and checking refresh_expires in response.
The refresh tokens lifespan is defined by the "Client Session Max" parameter in the "Tokens" tab of the Realm settings.
It can also be overridden on individual clients level under the "Advanced Settings" menu of the client settings page.
Like stated in the Keycloak docs: https://www.keycloak.org/docs/latest/server_admin/#_timeouts
Client Session Max
The maximum time before a refresh token is
expired and invalidated. It allows for the specification of a shorter
timeout of refresh token than session timeout. And it can be
overridden on individual clients. It is an optional configuration and
if not set to a value bigger than 0 it uses the same idle timeout set
in the SSO Session Max configuration.
Related
I am working with Identity Server 3 on the service and oidc-client.js in my front end. The client setup in Identity Server does not set the token lifetime options, so should have the default values of 300s (5min) for the identity token lifetime and 3600s (60min or 1hr) for the access token lifetime. My client app requests and receives both an identity token and an access token. The oidc-client user object exposes expiration information about the access token. But how can I tell when the identity token has expired? Or maybe more to the point, which token should represent a still valid login/authentication? My code is currently using the user object expiration data to determine if a user is authenticated, but now that I realize that's the access token expiration, I'm not sure that's the right thing to do.
Same question asked another way: If a user logs in and gets an identity token that's valid for 5 minutes and an access token that's valid for 60 minutes, when does that user's authentication expire and how does the client app know it has expired?
We have a secure app which needs a very short access token validity period (for example, 15 mins). We would like the access token to remain active while the user is active and making API calls. However, once there is 15 mins of inactivity it should expire. Essentially, the expiration time shouldn't be fixed, but rather 15 mins from last call.
What is a good pattern to use for this model? Is this possible with OAuth2.
OAuth 2.0 doesn't specify how an access token can be validated. That is up to an agreement between the Resource Server (i.e. your API) and the Authorization Server so you're free in your implementation to gear it towards the scenario that you describe.
Either your Resource Server needs to track the inactivity timeout or the Authorization Server can do it and the Resource Server needs to call out on each usage to the Authorization Server to track usage and activity there.
I have implemented openid connect authentication using azure active directory in my website. The session expires every 1 hour. So the user is logged out, and redirected back to the login page. While analyzing based on it, i have found a solution in the below link, to use UseTokenLifetime = false
https://github.com/aspnet/Security/issues/147
Will this fix my issue? or is there any chance of increasing the session time?
Thanks in advance
Dinesh
Read here to learn more about Configurable Token Lifetime
In general, access tokens have a very short lifetime. This is intentional. Your web application should be using the refresh token which comes with your access token to acquire new access tokens once the original one expires.
When you get an access token and refresh token (assuming all default settings), the access token will last up to one hour. The refresh token will allow you to get a new access token + refresh token pair for up to 14 days. The new refresh token you get will last another 14 days, allowing you to chain new access tokens up to a total of 90 days, where you will need to eventually ask the user to sign in again.
You have the ability to configure token lifetimes such that your "refresh token chain" will never expire, however any individual access token or refresh token will eventually expire.
Is there any maximum number of requests to get a brand new access token using a refresh token?
Yes. 25 according to Google's developer documentation
Access tokens have a lifetime of 3600 seconds. Requesting a new access token before that time is up works fine but it's inefficient for your app to do so often. I don't think Google publishes a limit on how many non-expired access tokens a refresh token can have but you may get errors and it's non-optimal.
For most apps, refreshing an access token 10 minutes before the current access token expires (later if your not to worried about clock drift) works well.
The number of requests depend on the authorization server security policy.
Some servers allow only one request (the refresh token is invalidate after the request), other servers may allow 10, 100 or even unlimited requests.
I have integrated tokbox in my app for live call, signaling.
My problem is session & token expire at every 1 hour. So is this valid?
What is the validity(time limit) of any session & token?
How to solve this problem
please guide us.
thank you.
OpenTok sessions do not expire. However, authentication tokens do expire. Also, note that sessions cannot explicitly be destroyed.
OpenTok tokens expire after a set period of time (max up to 30 days). You can specify the expiration period when you generate the token. Read this https://tokbox.com/developer/guides/create-token/
While working on a test version of your app, you can obtain a test session ID and token using the Dashboard page. But every production OpenTok application should be generating these values dynamically on a server, using one of their many Server SDKs (PHP, node, Ruby, Python, .NET, Java)