25 lines
3 KiB
Text
25 lines
3 KiB
Text
|
|
[[_authentication-sessions]]
|
|
=== Authentication sessions
|
|
|
|
When a login page is opened for the first time in a web browser, {project_name} creates an object called authentication session that stores some useful information about the request.
|
|
Whenever a new login page is opened from a different tab in the same browser, {project_name} creates a new record called authentication sub-session that is stored within the authentication session.
|
|
Authentication requests can come from any type of clients such as the Admin CLI. In that case, a new authentication session is also created with one authentication sub-session.
|
|
Please note that authentication sessions can be created also in other ways than using a browser flow.
|
|
|
|
The authentication session usually expires after 30 minutes by default. The exact time is specified by the *Login timeout* switch in the *Sessions* tab of the admin console when <<configuring-realms,configuring realm>>.
|
|
|
|
==== Authentication in more browser tabs
|
|
|
|
As described in the previous section, a situation can involve a user who is trying to authenticate to the {project_name} server from multiple tabs of a single browser. However, when that user authenticates in one browser tab,
|
|
the other browser tabs will automatically restart the authentication. This authentication occurs due to the small javascript available on the {project_name} login pages. The restart will typically
|
|
authenticate the user in other browser tabs and redirect to clients because there is an SSO session now due to the fact that the user just successfully authenticated in first browser tab.
|
|
Some rare exceptions exist when a user is not automatically authenticated in other browser tabs, such as for instance when using an OIDC parameter _prompt=login_ or <<_step-up-flow, step-up authentication>> requesting a stronger
|
|
authentication factor than the currently authenticated factor.
|
|
|
|
In some rare cases, it can happen that after authentication in the first browser tab, other browser tabs are not able to restart authentication because the authentication session is already
|
|
expired. In this case, the particular browser tab will redirect the error about the expired authentication session back to the client in a protocol specific way. For more details, see the corresponding sections
|
|
of *OIDC documentation* in the link:{securing_apps_link}[securing apps] section and link:{adapterguide_link}#_saml-errors[SAML documentation]. When the client application receives such an error, it can immediately resubmit the OIDC/SAML authentication request to {project_name} as
|
|
this should usually automatically authenticate the user due to the existing SSO session as described earlier. As a result, the end user is authenticated automatically in all browser tabs.
|
|
The *Keycloak JavaScript adapter* in the link:{securing_apps_link}[securing apps] section, link:{adapterguide_link}#_saml[{project_name} SAML adapter], and <<_identity_broker, {project_name} Identity provider>>
|
|
support to handle this error automatically and retry the authentication to the {project_name} server in such a case.
|