libre.sh/keycloak-scim
2
0
Fork 0
Code Issues 14 Pull requests Releases Packages Activity Actions 6

DPoP release notes and documentation polishing

Browse source 
closes #21922
This commit is contained in:
mposolda 2023-08-07 11:28:40 +02:00 committed by Marek Posolda
parent 2dec99c443
commit 710f28ce9e
2 changed files with 12 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
docs/documentation/release_notes/topics/23_0_0.adoc
View file

@ -9,4 +9,9 @@ See the migration guide for more details.
Keycloak has new client profiles `fapi-2-security-profile` and `fapi-2-message-signing`, which ensure Keycloak enforces compliance with
the latest FAPI 2 draft specifications when communicating with your clients. Thanks to https://github.com/tnorimat[Takashi Norimatsu] for the contribution.
= DPoP preview support
Keycloak has preview for support for OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP). Thanks to
https://github.com/tnorimat[Takashi Norimatsu] and https://github.com/dteleguin[Dmitry Telegin] for their contributions.

10
docs/documentation/server_admin/topics/clients/oidc/con-advanced-settings.adoc
View file

@ -101,7 +101,7 @@ DPoP binds an access token and a refresh token together with the public part of
This type of token is a holder-of-key token. Unlike bearer tokens, the recipient of a holder-of-key token can verify if the sender of the token is legitimate.
If this setting is on, the workflow is:
If the client switch `OAuth 2.0 DPoP Bound Access Tokens Enabled` is on, the workflow is:
. A token request is sent to the token endpoint in an authorization code flow or hybrid flow.
. {project_name} requests a DPoP proof.
@ -110,11 +110,15 @@ If this setting is on, the workflow is:
If verification fails, {project_name} rejects the token.
In the following cases, {project_name} will verify the client sending the refresh token:
If the switch `OAuth 2.0 DPoP Bound Access Tokens Enabled` is off, client can still send `DPoP` proof in the token request. In that case, {project_name} will verify DPoP proof
and will add the thumbprint to the token. But if the switch is off, DPoP binding is not enforced by {project_name} server for this client. It is recommended to have this switch
on if you want to make sure that particular client always uses DPoP binding.
In the following cases, {project_name} will verify the client sending the access token or the refresh token:
* A token refresh request is sent to the token endpoint with a holder-of-key refresh token. This verification is done only for public clients as described in the DPoP specification. For confidential clients, the verification is not done as client authentication with proper client credentials is in place to ensure that request comes from the legitimate client. For public clients, both access tokens and refresh tokens are DPoP bound. For confidential clients, only access tokens are DPoP bound.
* A UserInfo request is sent to UserInfo endpoint with a holder-of-key access token.
* A logout request is sent to a non-OIDC compliant {project_name} proprietary logout endpoint Logout endpoint with a holder-of-key refresh token. This request is done only for public clients as described above.
* A logout request is sent to a non-OIDC compliant {project_name} proprietary logout endpoint Logout endpoint with a holder-of-key refresh token. This verification is done only for public clients as described above.
See https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop[OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)] for more details.