Non-templatized (Section)#
Path: /profiles/profile{id, type}/settings/authorization-server/dynamic-client-registration/non-templatized
Allow new clients to be registered which are not based on any existing client configuration
Parameters#
| Name | Type | Required | Default | Description |
|---|---|---|---|---|
| require-secured-authorization-response | empty | optional | If set, then all authorization responses need to be protected according to the ‘JWT Secured Authorization Response Mode for OAuth 2.0’ (JARM) specification | |
| require-request-object | empty | optional | If set, all authorization requests made by non-templatized dynamic clients must include a request object | |
| require-id-token-encryption | empty | optional | If set, a client must register with ID token encryption settings. Requires OpenId Connect to be enabled for the profile and the openid scope to be allowed by DCR. | |
| default-refresh-token-ttl | uint32 | optional | 3600 | The number of seconds the refresh token will be valid. This value can be overridden by the client in the registration request. Setting this value to 0 means that it no refreshtoken will be issued by default. |
| default-refresh-token-max-rolling-lifetime | uint32 | optional | When set, the default-refresh-token-ttl or the registration overridden value are used to set the expiration of new refresh tokens, until this max value defined in seconds is reached. | |
| authenticator-filters | multi-value, leafref | optional | A subset of the authenticator-filters that new clients may use to filter out certain authenticators during login | |
| enable-subject-dn-as-client-id-override | boolean | optional | true | When enabled, the certificate that a client uses for mutual-tls for authentication (direct or by proxy) will be processed such that if its Subject DN contains an OrganizationID (i.e. an RDN with OID 2.5.4.97), this OrganizationID will be used as the client_id that the new client is registered with. When disabled, the a client_id is generated. Defaults to true. |
| credential-manager | leafref | optional | The credential manager that should be used to verify and manage non-templatized dynamic clients’ secrets(notice that this setting is obsolete) | |
| validate-port-on-loopback-interfaces | boolean | optional | true | Whether 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 a redirect-uri-validation-policy is set, in which case the chosen redirect-uri-validation-policy is used. If validate-port-on-loopback-interfaces is not set, the default redirect-uri-validation-policy of the profile will be used. This setting is deprecated in favour of redirect-uri-validation-policies. |
| redirect-uri-validation-policy | leafref | optional | The redirect uri validation policy to use for all non-templatized clients. This can not be overridden by a non-templatized client. |
Subsections#
| Name | Type | Description |
|---|---|---|
| capabilities | Section | None |
| scopes | Section | The scopes that new clients may register with |
| authenticators | Section | The authenticators that new clients may authenticate with |
| backchannel-authenticators | Section | The backchannel authenticators that new clients may authenticate with |
| client-authentication-method | Section | Configures how a client authenticates to token, introspect, etc. endpoints. |
| authentication-method | OneOf | Configure the authentication method that is needed to make the call to register a new client |
| sector-identifier-http-clients | Section | A list of sectors and their associated HTTP client that will be used to validate a request for a dynamic client to be in a certain sector. When a non-templatized request is made for some sector that is not configured, the default SSL context, name verifier, trust anchors, etc. will be used. |
| http-client-mappings | Section | The list of HTTP client mappings. Each mapping associates an URL and an usage set to the HTTP client ID that should be used in that context |
| user-consent | Section | When 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). Note that CIBA is not an interactive flow and will always fail if this is enabled. |
| signed-userinfo-token-issuers | Section | Enable support for returning userinfo as signed JWT |
| signed-id-token-issuers | Section | Configure how a signed id-token can be returned for dynamically registered clients. If this container is not present, the profile’s token issuer settings will be applicable. |
| require-pushed-authorization-requests | Section | Clients must register with require-pushed-authorization-requests; if this is not enabled here, the profile settings for require-pushed-authorization-requests are followed. |