42

I'm currently setting up Keycloak to offer protection for some services. There will be both external customers and internal services consuming the same endpoints on my services.

Can I set the token expiry on a user or role or client level, or use a mix of tokens and Basic auth?

Yuri
  • 4,254
  • 1
  • 29
  • 46
Michael
  • 1,347
  • 1
  • 13
  • 27
  • I need exactly this (particularly to set different expiration times based on client basis). Did you finally achieve it? Cheers. – jbernal Jun 19 '17 at 15:45
  • I do not see from keycloak admin console how this is possible. Is there any keycloak guru out there that knows whether it is possible? In my case we are using 4.0.0 Final. – mtsahakis Aug 15 '18 at 08:50
  • 2
    There is surely a need for _service_ user accounts. Eg. TV panels displaying a webpage – Yuri Apr 15 '20 at 07:42

4 Answers4

54

It is possible to configure a different lifespan for access tokens on a per client basis. In Keycloak admin console go to a client settings page and expand the "Advanced Settings" section.
This screenshot is taken from Keycloak 4.8.1.Final.

enter image description here

EDIT: Be aware that is override is applied to Authorization Code Flow only. The access token lifespan for Implicit Flow can still (Keycloak 7.0.0) be set on realm level only!

EDIT: Since Keycloak 10.0.0 it is also possible to override session idle and session max timeout per client.

enter image description here

Boomer
  • 3,360
  • 20
  • 28
12

enter image description here

It can be done on realm only, correctly mentioned by @maslick as Keycloak do SSO and expects multiple clients in one realm.

Although, you can code accordingly in your application picking the Keycloak session if you need it to be custom.

codeogeek
  • 652
  • 1
  • 8
  • 22
2

Can I set the token expiry on a user or role or client level, or use a mix of tokens and Basic auth?

Currently, Keycloak does not offer (out-of-the-box) user- or role-based token expiration. IMO no one in this thread has yet covered how the SSO-related fields influence the access token lifespan. It is also missing references to ID and refresh tokens. I will try to expand on this.

Refresh Token lifespan

Currently, the refresh token lifespan cannot be explicitly set. Nonetheless, one can implicitly set the refresh token by tuning the values SSO Session Idle, Client Session Idle, SSO Session Max, and Client Session Max. One can read more about it on this SO answer.

ID and Access tokens lifespan

TL;DR One can infer that the ID and access token lifespan will be equal to the smallest value among (Access Token Lifespan, SSO Session Max, and Client Session Max).

In Keycloak (KC), one can explicitly set the access token lifespan (ATL) at the realm and client levels. Those options are not available for the ID token lifespan, but KC will make it the same as the ATL. Therefore, when one changes the ATL, one indirectly sets the ID token.

By default, the ATL is 5 minutes (except for implicit flow which is 15 minutes). One can change those values at: Realm > Realm Settings > Tokens. How it looks on the:

  • old KC UI:

enter image description here

  • new KC UI:

enter image description here

Even though the fields are labeled as 'Access Token', KC uses (as previously mentioned) their values to also set the ID Token lifespan as well.

Those values can be overridden on a per-client basis in Ones Realm > Clients > ones Client, then on the:

  • old KC UI, one goes to the section Advanced Settings

enter image description here

  • new KC UI, one switches to the tab Advanced and goes to the section Advanced Settings

enter image description here

So far so good, but now things will get a bit more interesting.

Interplay with SSO-related fields

As with the refresh token lifespan, the ATL also depends on other values, namely:

  • SSO Session Max
  • and Client Session Max.

Let us consider for now only the realm settings SSO Session Max and Access Token Lifespan, when:

  • SSO Session Max > Access Token Lifespan, then ATL = Access Token Lifespan
  • SSO Session Max <= Access Token Lifespan, then ATL = SSO Session Max

So, one can infer that the ATL is bound to the smallest value between the Access Token Lifespan and the SSO Session Max, which makes sense.

SSO Session Max is related to Single Sign-ON; we still need to consider the value of Client Session Max in the realm settings, which when unset, is the same as SSO Session Max.

If Client Session Max is set, in the context of the ATL, it will override the value from SSO Session Max, BUT only if that value is lower than the value from SSO Session Max.

Let us see the following examples: Access Token Lifespan (at realm settings) = 30 minutes, SSO Session Max = 10 hours and:

  1. Client Session Max = 1 hour, then ATL is equal to the Access Token Lifespan
  2. Client Session Max = 60 seconds, then ATL is equal to the Client Session Max

So in short one can infer that the ATL will be equal to the smallest value amongst the fields Access Token Lifespan, SSO Session Max, and Client Session Max.

Finally, the fields Access Token Lifespan and Client Session Max from the realm settings can be overwritten respectively by the Access Token Lifespan and Client Session Max in the clients themselves, which will affect the ATL for that client in particular.

The same logic applies but instead of considering the values Access Token Lifespan and Client Session Max from the realm settings one needs to consider those from the client advance settings.

dreamcrash
  • 47,137
  • 25
  • 94
  • 117
0

Unfortunately, token expiration time can be set on a per-realm basis only.

maslick
  • 2,903
  • 3
  • 28
  • 50