Client (List)#

Path: /profiles/profile{id, type}/settings/authorization-server/client-store/config-backed/client

Parameters#

NameTypeRequiredDefaultDescription
idnon-empty-stringrequiredThe client ID corresponding to the spec
client-namenon-empty-stringoptionalA human readable name of the client
descriptionstringoptionalA human readable description of the client
logostringoptionalA logo of the client, that can shown in user interface templates.
redirect-urismulti-value, urioptionalThe whitelist of Redirect URIs allowed for the client. If code or Implicit flow is used, this will have a required minimum of 1 items
application-urlurioptionalThis URL is used if a request is made to the OAuth server without the parameters necessary to initiate authentication. In such a case, the user is redirected to this URL, so that a new, properly formed, request can be made to bootstrap a new authentication transaction.
enabledbooleanoptionaltrueA settable state of the client, to be able to host disabled clients
created-atdate-and-timeoptionalAn operational state, for history purpose
created-bystringoptionalDescribes who was the user that created the client.
access-token-ttltoken-time-to-liveoptional300The number of seconds an access token will be valid
refresh-token-ttldisablable-token-time-to-liveoptional3600The number of seconds a refresh token will be valid. If set to ‘disabled’, no refresh tokens will be issued
refresh-token-max-rolling-lifetimedisablable-token-time-to-liveoptionalWhen set, the refresh-token-ttl is used to set the expiration of new refresh tokens, until this max value is reached.
id-token-ttltoken-time-to-liveoptionalThe number of seconds an id token will be valid. If not set, the profile-setting is used.
audiencemulti-value, stringoptionalThe intended audiences for the token. The first element is the default. If none are stipulated, the ID of the client will be used as the audience
scopemulti-value, leafrefoptionalA subset of the scopes defined in the profile that this client is allowed to request or all if a subset are not defined here
claims-mapperleafrefoptionalThe mapper to use when adding claims to tokens. The mapper decides what claims end up in which token or response. The claims themselves are defined in the scope. If not set, the default-mapper is used
allowed-originsmulti-value, non-empty-stringoptionalThe optional list of URIs or URI-patterns that is allowed to embed the rendered pages inside an iframe, be a trusted source or be used for CORS.
require-secured-authorization-responseemptyoptionalIf set, then all authorization responses need to be protected according to the ‘JWT Secured Authorization Response Mode for OAuth 2.0’ (JARM) specification
privacy-policy-urlurioptionalAn absolute URL that refers to the privacy policy for the client
terms-of-service-urlurioptionalAn absolute URL that refers to the terms of service of the client
validate-port-on-loopback-interfacesbooleanoptionaltrueWhether the port should be validated when a client is configured to redirect to the loopback interface. Defaults to true for backwards compatibility. Future versions may default to false because RFC-8252 (sec. 3) says the port should not be validated and this does not generally reduces the security of local redirects. This option can not be set when the profile enables redirect-uri validation policies. This setting is deprecated in favour of redirect-uri-validation-policies.
redirect-uri-validation-policyleafrefoptionalThe redirect uri validation policy to use for this client. This value overrides the profile’s setting for the default redirect uri validation policy.
reuse-refresh-tokensbooleanoptionalDefines if refresh tokens are created on every refresh or if they are kept, when set this takes precedence over profile setting (reuse-refresh-tokens), when not set profile setting applies

Subsections#

NameTypeDescription
verifier OneOfDescribes how the client is authenticated
assertion-jwt-validation SectionValidate the assertion JWT used for client authentication according to RFC-7523 (e.g. optional jti; iss and sub don’t have to be equal) instead of OpenID Connect Core (which is done by default).
secondary-authentication-method SectionNone
request-object SectionEnable request-object support where the client can send in a JWT with the request parameters. If enabled, a request object JWT MUST be provided by the client.
user-consent SectionWhen set, the user is asked to accept the delegation via a consent screen. This applies to all interactive flows (i.e. code, implicit, assisted token and device authorization flow)
proof-key SectionProof Key for Code Exchange (RFC 7636 - PKCE) is a measure for preventing authorization code interception. This is an attack on client systems that allow a malicious application to register itself as a handler for the custom scheme utilized by the legitimate app in the Authorization Code Grant flow.
user-authentication SectionNone
capabilities SectionOAuth capabilities that this client is allowed to perform
dynamic-client-registration-template SectionEnable client as template for Dynamic Client Registration
use-pairwise-subject-identifiers SectionEnable this when the client must always be issuing pairwise pseudonym subject identifiers instead of public identifiers.
signed-userinfo SectionEnable support for returning userinfo as signed JWT
id-token-encryption SectionEnable Id token encryption as per JWE specification
attestation SectionNone
properties SectionList of properties that can be configured on a client. These properties can be used from procedures to retrieve properties of the configured client.

Was this helpful?