Creating templatized clients only require a single parameter to indicate which client template to instantiate.
software_id
When creating a regular DCR client the request is a combination of grant_types and additional settings depending on what grant_types are requested.
grant_types
access_token_ttl
allow_per_request_redirect_uris
allowed_origins
application_url
authenticator_filters
authorization_signed_response_alg
backchannel_authentication_request_signing_alg
backchannel_client_notification_endpoint
-
backchannel_logout_uri
backchannel_token_delivery_mode
poll
backchannel_user_code_parameter
client_name
client_secret_expires_at
client_uri
default_max_age
max_age
default_acr_values
disallowed_proof_key_challenge_methods
frontchannel_logout_uri
authorization_code
client_credentials
https://curity.se/grant/assisted-token
implicit
urn:ietf:params:oauth:grant-type:device_code
urn:openid:params:grant-type:ciba
password
id_token_encrypted_response_alg
id_token_encrypted_response_enc
id_token_signed_response_alg
id_token_ttl
initiate_login_uri
jwks
token_endpoint_auth_method
jwks_uri
logo_uri
policy_uri
post_logout_redirect_uris
redirect_uris
refresh_token_max_rolling_lifetime
refresh_token_ttl
0
request_object_signing_alg
request_uris
require_proof_key
require_pushed_authorization_requests
requires_consent
scope
sector_identifier_uri
subject_type
public
pairwise
tls_client_auth_subject_dn
token_endpoint_auth_signing_alg
tos_uri
userinfo_signed_response_alg
The template area (to be used by authenticators during OAuth flows) for a non-templatized DCR client can be set using a pre-processing procedure only. Sending a template_area field in a registration request will result in the field being stored the same way as any other custom property (described below). This template_area (the one sent via a registration request) will have no effect on what template area authenticators will use during OAuth flows ran by the registered non-templatized DCR client.
template_area
In a scenario where a template_area field is sent in a registration request and it is set also in a pre-processing procedure, the template_area from the request will be stored as a custom property, and the template_area from the pre-processing procedure will be stored as well and it will be used by authenticators (so the two template areas will not overwrite one another).
1 2 3 4 5
function result(context) { return { template_area: "custom-area" } }
It is possible to send custom properties that should be stored as client properties. Any non standard parameter will be recognized as a custom client property and stored as such. These are later available when issuing tokens etc.