Dpop (Section)#

Path: /profiles/profile/settings/authorization-server/client-store/config-backed/client/dpop

Per-client DPoP binding policy for non-HAAPI flows. Each option that is set to a value other than ‘inherit-from-profile’ explicitly overrides the corresponding profile default for this client; an option left at ‘inherit-from-profile’ (the default) applies the profile value. HAAPI flows are governed by the separate settings under the HAAPI capability, so these settings must not be configured on a HAAPI client. The accepted proof signing algorithms are profile-wide and cannot be set here.

Parameters#

NameTypeRequiredDefaultDescription
authorization-code-dpop-bindingenumeration (inherit-from-profile, required, client-requested)optionalinherit-from-profileWhether the authorization code must be DPoP-bound. When ‘required’, the authorize request must carry the dpop_jkt authorization request parameter; when ‘client-requested’, the code is bound only if dpop_jkt is supplied. When ‘inherit-from-profile’ (the default), the profile value applies.
token-dpop-bindingenumeration (inherit-from-profile, required, client-requested)optionalinherit-from-profileWhether the token request must carry a valid DPoP proof. When ‘required’, a token request without a valid proof is rejected; when ‘client-requested’, tokens are bound only when a proof is presented. When ‘inherit-from-profile’ (the default), the profile value applies.
public-client-tokens-to-bind-with-dpopenumeration (inherit-from-profile, refresh-token-only, access-token-and-refresh-token)optionalinherit-from-profileWhich tokens this public client gets DPoP-bound when DPoP is used. This setting is meaningful for public clients only; a confidential client is always access-token-only and must not override it. When ‘inherit-from-profile’ (the default), the profile value applies.

Was this helpful?