mirror/keycloak
1
0
Fork 0
mirror of https://github.com/keycloak/keycloak.git synced 2026-02-21 22:59:00 -06:00
Code Issues Packages Projects Releases Wiki Activity

FAPI 2.0 Security Profile Final - Documentation

Browse Source 
closes #41121

Signed-off-by: Takashi Norimatsu <takashi.norimatsu.ws@hitachi.com>
This commit is contained in:
Takashi Norimatsu
2025-07-23 13:38:05 +09:00
committed by Marek Posolda
parent 43610cfa67
commit cb4e06b6f8
2 changed files with 3 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/documentation/server_admin/topics/sso-protocols/con-oidc-auth-flows.adoc
View File

@@ -89,7 +89,7 @@ It is possible to specify that the refresh token is considered invalid once it i
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 *FAPI 2 draft specification* in the link:{securing_apps_link}[securing apps] section.
return new refresh tokens. This practice is recommended for instance in the *FAPI 2 draft specification* and *FAPI 2 final specification* in the link:{securing_apps_link}[securing apps] section.
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.

3
docs/guides/securing-apps/partials/oidc/fapi-support.adoc
View File

@@ -8,6 +8,7 @@
* https://openid.net/specs/openid-financial-api-ciba-ID1.html[Financial-grade API: Client Initiated Backchannel Authentication Profile] (FAPI CIBA)
* https://openid.bitbucket.io/fapi/fapi-2_0-security-profile.html[FAPI 2.0 Security Profile (Draft)]
* https://openid.bitbucket.io/fapi/fapi-2_0-message-signing.html[FAPI 2.0 Message Signing (Draft)]
* https://openid.net/specs/fapi-security-profile-2_0-final.html[FAPI 2.0 Security Profile (Final)]
This compliance means that the {project_name} server will verify the requirements
for the authorization server, which are mentioned in the specifications. {project_name} adapters do not have any specific support for the FAPI, hence the required validations on the client (application)
@@ -17,7 +18,7 @@ side may need to be still done manually or through some other third-party soluti
To make sure that your clients are FAPI compliant, you can configure Client Policies in your realm as described in the link:{adminguide_link}#_client_policies[{adminguide_name}]
and link them to the global client profiles for FAPI support, which are automatically available in each realm. You can use either `fapi-1-baseline` or `fapi-1-advanced` profile based on which FAPI
profile you need your clients to conform with. You can use also profiles `fapi-2-security-profile` or `fapi-2-message-signing` for the compliance with FAPI 2 Draft specifications.
profile you need your clients to conform with. You can use also profiles `fapi-2-security-profile` or `fapi-2-message-signing` for the compliance with FAPI 2 Draft specifications and `fapi-2-security-profile-final` or `fapi-2-dpop-security-profile-final` for the compliance with FAPI 2 Final specifications.
In case you want to use link:{adminguide_link}#_oidc_clients[Pushed Authorization Request (PAR)], it is recommended that your client use
both the `fapi-1-baseline` profile and `fapi-1-advanced` for PAR requests. Specifically, the `fapi-1-baseline` profile contains `pkce-enforcer` executor, which makes sure