libre.sh/keycloak-scim
4
0
Fork 0
Code Issues 15 Pull requests Releases 1 Activity Actions

Documentation for SuppressRefreshTokenRotationExecutor

Browse source 
closes #26587

Signed-off-by: mposolda <mposolda@gmail.com>

Co-authored-by: andymunro <48995441+andymunro@users.noreply.github.com>
This commit is contained in:
mposolda 2024-01-31 18:48:49 +01:00 committed by Marek Posolda
parent 5d39625d82
commit 56a605fae7
2 changed files with 26 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
docs/documentation/server_admin/topics/clients/client-policies.adoc
View file

@ -76,7 +76,8 @@ Client Scope::
OIDC authorization requests with scope `fapi-example-scope` need to be FAPI compliant.
Client Role::
Applies for clients with the client role of the specified name
Applies for clients with the client role of the specified name. Typically you can create a client role of specified name to requested clients and use it as a "marker role" to make
sure that specified client policy will be applied for requested clients.
Client Domain Name, Host or IP Address::
Applied for specific domain names of client. Or for the cases when the administrator registers/updates client from particular Host or IP Address.
@ -105,7 +106,7 @@ on the OIDC authorization request). Events are:
* Sending a token revocation request
* Sending a token introspection request
* Sending a userinfo request
* Sending a logout request with a refresh token
* Sending a logout request with a refresh token (note that logout with refresh token is proprietary {project_name} functionality unsupported by any specification. It is rather recommended to rely on the <<_oidc-logout,official OIDC logout>>).
On each event, an executor can work in multiple phases. For example, on creating/updating a client, the executor can modify the client configuration by autoconfigure specific client
settings. After that, the executor validates this configuration in validation phase.
@ -129,6 +130,7 @@ One of several purposes for this executor is to realize the security requirement
* Enforce checking if a PAR request includes necessary parameters included by an authorization request
* Enforce <<_dpop-bound-tokens,DPoP-binding tokens>> is used (available when `dpop` feature is enabled)
* Enforce <<_using_lightweight_access_token, using lightweight access token>>
* Enforce that <<_refresh_token_rotation,refresh token rotation>> is skipped and there is no refresh token returned from the refresh token response
[[_client_policy_profile]]
=== Profile

23
docs/documentation/server_admin/topics/sso-protocols/con-oidc-auth-flows.adoc
View file

@ -72,6 +72,27 @@ The _Client Credentials Grant_ creates a token based on the metadata and permiss
See the <<_service_accounts,Service Accounts>> chapter for more information.
[[_refresh_token_grant]]
==== Refresh token grant
By default, {project_name} returns refresh tokens in the token responses from most of the flows. Some exceptions are implicit flow or client credentials grant described above.
Refresh token is tied to the user session of the SSO browser session and can be valid for the lifetime of the user session. However, that client should send a refresh-token request at least once per
specified interval. Otherwise, the session can be considered "idle" and can expire. See the <<_timeouts,timeouts section>> for more information.
{project_name} supports <<_offline-access,offline tokens>>, which can be used typically when client needs to use refresh token even if corresponding browser SSO session is already expired.
[[_refresh_token_rotation]]
===== Refresh token rotation
It is possible to specify that the refresh token is considered invalid once it is used. This means that client must always save the refresh token from the last refresh response because older refresh tokens,
which were already used, would not be considered valid anymore by {project_name}. This is possible to set with the use of _Revoke Refresh token_ option as specified in the <<_timeouts,timeouts section>>.
{project_name} also supports the situation that no refresh token rotation exists. In this case, a refresh token is returned during login, but subsequent responses from refresh-token requests will not
return new refresh tokens. This practice is recommended for instance in the link:{adapterguide_link}#_fapi-support[FAPI 2 draft specification].
In {project_name}, it is possible to skip refresh token rotation with the use of <<_client_policies,client policies>>. You can add executor `suppress-refresh-token-rotation` to some client
profile and configure client policy to specify for which clients would be the profile triggered, which means that for those clients the refresh token rotation is going to be skipped.
===== Device authorization grant
This is used by clients running on internet-connected devices that have limited input capabilities or lack a suitable browser. Here's a brief summary of the protocol:
@ -292,7 +313,7 @@ User Resolver Provider is provided as SPI provider so that users of {project_nam
==== OIDC Logout
OIDC has four specifications relevant to logout mechanisms. These specifications are in draft status:
OIDC has four specifications relevant to logout mechanisms:
. https://openid.net/specs/openid-connect-session-1_0.html[Session Management]
. https://openid.net/specs/openid-connect-rpinitiated-1_0.html[RP-Initiated Logout]