Code (Section)#

Path: /profiles/profile/settings/authorization-server/client-capabilities/code

Parameters#

NameTypeRequiredDefaultDescription
authorization-code-ttluint32optional30The number of seconds an authorization code will be valid
disallowed-proof-key-challenge-methodsmulti-value enumeration (plain, S256)optional-A list of proof key challenge methods the clients aren’t allowed to use. Useful when one of the methods provided by the server is deemed insecure. This setting affects all the clients. Clients can have additional methods disallowed in their settings.
pushed-authorization-request-authorization-request-parameter-handlingenumeration (error-if-outside-except-oauth-parameters, ignore-outside-but-must-match-if-inside)optionalerror-if-outside-except-oauth-parametersHow claims in pushed authorization requests and parameters (form or query string) are validated for authorization requests arising from a pushed request.
allow-per-request-redirect-urisemptyoptional-When enabled, all clients can enable per-request redirect-uri’s when using pushed authorization requests. This option can not be used together with redirect-uri-validation-policies. In order to use redirect-uri-validation-policies, this option to allow-per-request-redirect-uris must be disabled. This setting is deprecated in favour of redirect-uri-validation-policies.
authorization-code-dpop-bindingenumeration (required, client-requested)optionalclient-requestedDefault for clients that do not override it in their dpop settings: when ‘required’, the authorization code must be DPoP-bound (the authorize request must carry the dpop_jkt authorization request parameter); when ‘client-requested’, the code is bound only if dpop_jkt is supplied. Does not affect HAAPI flows, which have their own DPoP settings under the HAAPI capability.

Subsections#

NameTypeDescription
require-pushed-authorization-requests SectionRequire all clients in this profile to use pushed authorization requests to initiate the code flow.

Was this helpful?