OAuth 2.0 Static Client
clientId) Must be unique across all static clients of this AS.
clientName) An optional human readable name of this client for display purposes.
redirectUris) Allowed Redirect URIs of this client.
Required if the client is used in a flow requiring redirect URIs, e.g. the Authorization Code Grant.
Notice that any Redirect URI sent by the client must match exactly one of the configured URIs in this property. No prefix or regular expression matching is performed.
filterRequestedScopes) Whether to filter all requested scopes against those configured in 'Allowed/Default Scopes'.
Applies to: OAuth 2.0 Authorization Code Grant, OIDC Authorization Code / Hybrid Flow, Client Credentials Grant and Token Exchange Grant.
If disabled, all requested scopes are accepted for further processing.
If enabled, only scopes also explicitly configured in 'Allowed/Default Scopes' are accepted for this client. If that list is empty, the request is treated as if the client had not requested any scopes at all.
Notice: This property only affects the requested scopes. The configured scope policy, scope filtering and granted scope processors may still affect the final resulting scopes such that they might be different than the requested scopes even if this option is disabled.
allowedScopes) The list of allowed or default scopes for this client.
Applies to: OAuth 2.0 Authorization Code Grant, OIDC Authorization Code / Hybrid Flow, Client Credentials Grant and Token Exchange Grant.
When "Filter Requested Scopes" is disabled, this list is only relevant if a scope policy is chosen in the grant/flow that replaces the requested scopes with these default scopes.
When "Filter Requested Scopes" is enabled, all scopes requested by the client are always filtered against this list. If there are no allowed scopes, the request is treated as if the client had not requested any scopes at all.
Notice that for OpenID connect, the 'openid' scope does not have to be added to this list since it only acts as a marker for OpenID connect requests and will never be explicitly granted.
alwaysGrantedScopes) Applies to: OAuth 2.0 Authorization Code Grant and OIDC Authorization Code / Hybrid Flow only (not the Client Credentials nor Token Exchange Grant).
A list of technical scopes that the user doesn't have to grant explicitly in the OAuth 2.0 Authorization Code Grant or the OIDC Authorization Code / Hybrid Flow. Each scope listed here will always be granted by IAM implicitly. The scopes listed here are added to the implicitly granted scopes in the Authorization Code Grant/Flow. Always Granted Scopes are never persisted, even if a Consent Storage Repository is configured.pkceCodeChallengeMethodOverride) Overrides the default Proof Key for Code Exchange (PKCE, see RFC 7636) configuration of the Authorization Code Flow/Grant for this particular client.
This allows to either disable PKCE enforcement for this client if enforced by default or to enforce PKCE for this client if not enforced by default.
clientSecret) Required, for example, if the client secret is used for token endpoint authentication using a post parameter or basic authentication.
To generate a secure secret, the openssl utility can be used, e.g.
openssl rand -base64 32. If using an HMAC signature for ID tokens, the client secret length must suffice for the signature algorithm (e.g., 32 bytes for HS256). clientCertificates) jwksSettings) A JSON Web Key Set (JWKS) containing the keys that can be used by the client for authentication to the authorization server, e.g. when accessing the token endpoint (if configured to use private_key_jwt).
For this client to authenticate using private_key_jwt, either this property or at least one public key must be configured. However, both may not be configured at the same time, i.e. if a public key is configured, then this property must not be set.
publicKeys) Public keys that can be used by the client for authentication to the authorization server, e.g. when accessing the token endpoint (if configured to use private_key_jwt).
For this client to authenticate using private_key_jwt, either this property or a JWKS must be configured. However, both may not be configured at the same time, i.e. if a JWKS is configured, then this list must be empty.
accessTokenAudience) List of values that are added to the audience claim (aud) of the issued access tokens for this client.
The values configured here are combined with the values configured in the authorization server, duplicate values are discarded.
If there is one audience, the claim is written as a string, for multiple values as an array.
accessTokenCustomClaims) List of custom claims that are added to the issued access tokens for this client.
Multiple claims with the same name can be configured if each has a claim condition which ensures that only one of them will be included at runtime.
The following claims are automatically set by Airlock IAM and therefore will be ignored if defined as custom claim.issaudexpnbfiatjtirandomscope
The claims configured here are combined with the values configured in the authorization server. If claims configured here and in the authorization server have the same name, the claims configured here will override the ones configured at the authorization server level.
Note: This only works on Authorization Code Grant/Flow and Hybrid Flow. For the latter, both Hybrid Flow ID tokens (Authorization Endpoint and Token Endpoint) use this functionality. It only applies to JWT access token and not to opaque tokens.
Note: When "Persist Claims" is disabled, custom claims are collected when the Access Token is requested by an OAuth 2.0 client and not when the Access Token is issued. Therefore the values of the custom claims may change between issue and request time.
accessTokenDistributedClaims) List of distributed claims that are added to the issued access tokens for this client.
These claims allow providing a URL to a 3rd party claims provider in the response where additional claims may be obtained.
The claims configured here are combined with the values configured in the authorization server. If claims configured here and in the authorization server have the same name, the claims configured here will override the ones configured at the authorization server level.
Note: This only works on Authorization Code Grant/Flow and Hybrid Flow. For the latter, both Hybrid Flow ID tokens (Authorization Endpoint and Token Endpoint) use this functionality. It only applies to JWT access token and not to opaque tokens.
idTokenCustomClaims) List of custom claims that are added to the issued OpenID Connect ID tokens for this client.
Multiple claims with the same name can be configured if each has a claim condition which ensures that only one of them will be included at runtime.
The following claims are automatically set by Airlock IAM and therefore will be ignored if defined as custom claim.auth_timenonceacr
The claims configured here are combined with the values configured in the authorization server. If claims configured here and in the authorization server have the same name, the claims configured here will override the ones configured at the authorization server level.
Note: This only works on Authorization Code Grant/Flow and Hybrid Flow. For the latter, both Hybrid Flow ID tokens (Authorization Endpoint and Token Endpoint) use this functionality.
Note: When "Persist Claims" is disabled, custom claims are collected when the ID Token is requested by an OpenID Connect relying party and not when the ID Token is issued. Therefore the values of the custom claims may change between issue and request time.
idTokenDistributedClaims) List of distributed claims that are added to the issued OpenID Connect ID tokens for this client.
These claims allow providing a URL to a 3rd party claims provider in the response where additional claims may be obtained.
The claims configured here are combined with the values configured in the authorization server. If claims configured here and in the authorization server have the same name, the claims configured here will override the ones configured at the authorization server level.
Note: This only works on Authorization Code Grant/Flow and Hybrid Flow. For the latter, both Hybrid Flow ID tokens (Authorization Endpoint and Token Endpoint) use this functionality.
backChannelLogoutUri) If defined, this client will support OpenID Connect Back-Channel Logout 1.0 in accordance with the OpenID Connect Back-Channel Logout Specification.
When a logout is initiated, a subsequent back channel logout request is sent to the configured URI, provided that the client has completed at least one OpenID Connect Authorization Code Flow or Hybrid Flow.
If no URI is specified, or if "Delete Tokens on Logout" is set to "None" in the "OAuth 2.0/OIDC Authorization Server" settings, no logout request will be sent.
httpClient) The HTTP client that executes the back-channel logout request for this static client.
Note that the HTTP client should be configured with a short 'Connect Timeout' and 'Read Timeout' (e.g. 5 seconds). This ensures a fast logout in case the back-channel logout request to the above specified URI times out.
Independent of the timeout configuration, a back-channel logout request to the above specified URI is canceled if no response is received within 30 seconds, so that the user's initial logout request won't be blocked for too long.
roleTransformations) A list of role transformation rules used to modify the collection of roles to propagate.
The role transformation rules are executed at the following locations in-order from top to bottom:
- OpenID Connect ID Token
- Access Token as JWT
- UserInfo Endpoint
- User Roles Resource
The role transformations defined here override those defined in "OAuth 2.0/OIDC Authorization Server".
flowApplicationId) When left empty, the setting in "OIDC Authorization Code / Hybrid Flow" or "OAuth 2.0 Authorization Code Grant" applies.
acrToFlowAppId) Maps an ACR value requested in the authentication request made by this client to an Application ID. The mappings defined here are merged with the mappings defined in "OIDC Authorization Code / Hybrid Flow"; if the same "ACR Value" is defined in "OIDC Authorization Code / Hybrid Flow" and here, the mapping configured here takes precedence.
How the application ID is selected:
- The merged ACR mappings (explained above) are evaluated first, if there is a match, the mapped Application ID is selected
- If there is no match, the flow is selected based on the Flow Application ID property:
- First at the level of the Static Client
- Then at the level of the Authorization Server ("OIDC Authorization Code / Hybrid Flow" or "OAuth 2.0 Authorization Code Grant")
- If both are not configured, the default application is selected
type: OAuth2StaticClient
id: OAuth2StaticClient-xxxxxx
displayName:
comment:
properties:
accessTokenAudience:
accessTokenCustomClaims:
accessTokenDistributedClaims:
acrToFlowAppId:
allowedScopes:
alwaysGrantedScopes:
backChannelLogoutUri:
clientCertificates:
clientId:
clientName:
clientSecret:
filterRequestedScopes: false
flowApplicationId:
httpClient:
idTokenCustomClaims:
idTokenDistributedClaims:
jwksSettings:
pkceCodeChallengeMethodOverride: DEFAULT
publicKeys:
redirectUris:
roleTransformations: