You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Allow different access_token expiration for different users
#12398
Currently the expiration of the access token is determined by a configuration in the realm that can be overriden by the client level only.
We are using keycloak as a federated authentication solution - where each tenant is on a different keycloak group (fortunately we have 1000s of tenants - so realm per tenant is not the scalable solution and users might have permission to multiple tenants)
The migration to using keycloak is kind of stuck on the fact that in our product - the customer can define the "stay signed in" period for his tenant. Something that the current functionality can't solve
I'll be happy to provide a pull-request to allow it based on a property at the group level (or even an official configuration if possible) but before I dive in I was wondering why the decision to have it only on the client level was made - is there a blocker I don't see from not knowing the design?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Currently the expiration of the access token is determined by a configuration in the realm that can be overriden by the client level only.
We are using keycloak as a federated authentication solution - where each tenant is on a different keycloak group (fortunately we have 1000s of tenants - so realm per tenant is not the scalable solution and users might have permission to multiple tenants)
The migration to using keycloak is kind of stuck on the fact that in our product - the customer can define the "stay signed in" period for his tenant. Something that the current functionality can't solve
I'll be happy to provide a pull-request to allow it based on a property at the group level (or even an official configuration if possible) but before I dive in I was wondering why the decision to have it only on the client level was made - is there a blocker I don't see from not knowing the design?
All reactions