2014-02-25 01:20:29 +00:00
|
|
|
<chapter id="timeouts">
|
2014-05-28 16:33:49 +00:00
|
|
|
<title>Cookie settings, Session Timeouts, and Token Lifespans</title>
|
2014-02-25 01:20:29 +00:00
|
|
|
<para>
|
2014-05-28 16:33:49 +00:00
|
|
|
Keycloak has a bunch of fine-grain settings to manage browser cookies, user login sessions, and token lifespans.
|
|
|
|
Sessions can be viewed and managed within the admin console for all users, and individually in the user's account
|
|
|
|
management pages. This chapter goes over configuration options for cookies, sessions, and tokens.
|
2014-02-25 01:20:29 +00:00
|
|
|
</para>
|
2014-05-28 16:33:49 +00:00
|
|
|
<section>
|
|
|
|
<title>Remember Me</title>
|
|
|
|
<para>
|
|
|
|
If you go to the admin console page of Settings->General, you should see a <literal>Remember Me</literal> on/off switch.
|
|
|
|
Your realm sets a SSO cookie so that you only have to enter in your login credentials once.
|
|
|
|
This <literal>Remember Me</literal> admin config option, when turned on, will show a "Remember Me" checkbox on the user's login page.
|
|
|
|
If the user clicks this, the realm's SSO. cookie will be persistent. This means that if the user closes their browser
|
|
|
|
they will still be logged in the next time they start up their browser.
|
|
|
|
</para>
|
|
|
|
</section>
|
|
|
|
<section id="session-timeouts">
|
|
|
|
<title>Session Timeouts</title>
|
|
|
|
<para>
|
2014-08-05 21:28:20 +00:00
|
|
|
If you go to the Sesions and Tokens->Timeout Settings page of the Keycloak adminstration console there is a bunch of fine tuning
|
2014-05-28 16:33:49 +00:00
|
|
|
you can do as far as login session timeouts go.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
The <literal>SSO Session Idle Timeout</literal> is the idle time of a user session. If there is no activity
|
|
|
|
in the user's session for this amount of time, the user session will be destroyed, and the user will become logged
|
|
|
|
out. The idle time is refreshed with every action against the keycloak server for that session, i.e.: a user login,
|
|
|
|
SSO, a refresh token grant, etc.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
The <literal>SSO Session Max Lifespan</literal> setting is the maximum time a user session is allowed to be alive. This
|
|
|
|
max lifespan countdown starts from when the user first logs in and is never refreshed. This works great with <literal>Remember Me</literal>
|
|
|
|
in that it allow you to force a relogin after a set timeframe.
|
|
|
|
</para>
|
|
|
|
</section>
|
|
|
|
<section>
|
|
|
|
<title>Token Timeouts</title>
|
|
|
|
<para>
|
|
|
|
The <literal>Access Token Lifespan</literal> is how long an access token is valid for. An access token contains everything
|
|
|
|
an application needs to authorize a client. It contains roles allowed as well as other user information. When
|
|
|
|
an access token expires, your application will attempt to refresh it using a refresh token that it obtained in the
|
|
|
|
initial login. The value of this configuration option should be however long you feel comfortable with the
|
|
|
|
application not knowing if the user's permissions have changed. This value is usually in minutes.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
The <literal>Access Code Lifespan</literal> is how long an access code is valid for. An access code is obtained
|
|
|
|
on the 1st leg of the OAuth 2.0 redirection protocol. This should be a short time limit. Usually seconds.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
The <literal>Access Code Action Lifespan</literal> is how long a user is allowed to attempt a login. When a user tries
|
|
|
|
to login, they may have to change their password, set up TOTP, or perform some other action before they are redirected
|
|
|
|
back to your application as an authentnicated user. This value is relatively short and is usually measured in minutes.
|
|
|
|
</para>
|
|
|
|
</section>
|
2014-02-25 01:20:29 +00:00
|
|
|
</chapter>
|