HTTP client used for token and pushed authorization endpoint requests.

HTTP Client Config HTTP Client With Client Certificate

Specifies how the client secret is included in requests to the token and pushed authorization request (PAR) endpoints.

RFC 6749 suggests to use the HTTP Basic authentication scheme ('OAuth 2.0 Basic Auth Client Secret').

OAuth 2.0 Basic Auth Client Secret OAuth 2.0 Header Client Secret OAuth 2.0 No Client Secret Authentication OAuth 2.0 Parameter Client Secret OIDC Private Key JWT Client Authentication

Token endpoint URL to get Access and Refresh Tokens.

https://airlock.com/auth/rest/oauth2/authorization-servers/asId/token

https://accounts.google.com/o/oauth2/token

https://login.live.com/oauth20_token.srf

Authorization endpoint URL to obtain Authorization Codes from.

https://airlock.iam/auth/ui/app/auth/oauth2/authorization-servers/asId/authorize

https://airlock.iam/auth/oauth2/v3/asId/authorize

https://accounts.google.com/o/oauth2/auth

https://login.live.com/oauth20_authorize.srf

The pushed authorization request endpoint URI to send the Authorization Request to. If this property is set, the OpenID Connect client will send all Authorization Requests according to the PAR specification as defined in RFC 9126.

https://airlock.iam/auth/rest/oauth2/authorization-servers/asId/par

https://as.example.org/as/par

Configures the PKCE challenge method.

S256

ID token signature validation plugin.

OIDC HS256 Signature Validator OIDC No Signature Validator OIDC RS256 Signature Validator

Defines the AS's logout endpoint URL. If configured, IAM notifies the AS that an end-user previously authenticated with this AS has logged out (RP-initiated logout).
Note that the AS must support this feature.

Scopes to request from the authorization endpoint. The scope 'openid' is always requested.

Scopes may only contain the following characters: 0-9, A-Z, a-z, !, #, $, %, &, ', (, ), *, +, ',', -, ., /, :, ;, <, >, =, ?, @, [, ], ^, _, `, {, }, |, ~

Allows requesting specific claims using the claims parameter as specified by the OpenID Connect Core Specification. The claims can be requested from the UserInfo Endpoint and/or in the ID Token. Note that support for the claims parameter by authorization servers is optional.

If the client wants to validate claims (e.g. returned in the ID Token), "Additional Claim Validators" can be configured. Note that the acr claim is validated separately. Refer to the property description of "Validate ACR Claim".

ID Token Claim UserInfo Claim

Authentication Context Class Reference (acr) values to request in order of preference from the authorization server (AS) using the acr_values parameter. The configured values are requested as voluntary claim as specified by the OpenID Connect Core Specification. If the AS supports this claim, the performed acr is included in the ID Token as 'acr' claim and validated according to "Validate ACR Claim". Note that the AS is not obligated to return the acr claim.

If the client wants to enforce a certain acr (e.g. to enforce strong authentication), "Additional Claim Validators" can be configured to validate if the requested acr is contained in the ID Token. Otherwise the authorization fails.

If enabled, a nonce is included in the authorization request and verified against the received ID Token. The nonce is used to associate a client session with an ID Token, and to mitigate replay attacks.

true

Whether or not the Loginapp should specifically request the currently used language for the user interaction at the authorization server.

false

Maximum age in seconds of a preexisting authenticated session at the authorization server. Forces re-authentication if the authenticated session is older than the specified value. This parameter is only included if the value is greater than 0. To always force authentication, use of the prompt parameter is recommended.

0

Prompt parameter value(s) sent during the OpenID Connect Authorization Code Flow. Used to either suppress or force user interaction at the authorization endpoint. If left empty, the prompt parameter will be omitted.

Available options:

none: Suppress all user interaction at the authorization server.

login: Force login at the authorization server.

consent: Force user consent at the authorization server.

select_account: Force the authorization server to prompt the end-user to select a user account.

Note: If the setting does not match the authorization server policy the authorization process may fail. For example, if user interaction is suppressed but login is required.

Custom authorization request parameters to be sent to the authorization server (AS). This can be used to define otherwise not configurable parameters such as login_hint or display as well as non-standard parameters.

Note: If a parameter is set both using the standard functionality and custom authorization request parameter, the standard parameter will take precedence.

OIDC Authorization Request Parameter

Issuer ('iss') claim expected during ID token validation. The issuer ('iss') value is a case-sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components.
If not set, the issuer URI in the ID Token is only compared to the host name of the authorization endpoint.

urn:windows:liveid

Audience claim validation method to use for the ID token validation.

Options:

• STANDARD: Standard audience claim validation as defined in the OpenID Connect Core specification.
• REDIRECT_URL: Compatibility option. The audience claim must be a valid URL and the host must match the host of the redirect URL used by Airlock IAM.
• CUSTOM: Compatibility option. The audience claim must exactly match a custom value supplied by 'Custom Audience Claim'.

STANDARD

Custom audience ('aud') claim to use for ID token validation. Some OpenID Connect providers may not adhere to the standard completely and successful ID token validation may therefore require to accept a custom audience ('aud') claim.

custom_audience

If enabled, acr values being requested by "ACR Values Claim" or "Claims To Request" are validated to be contained in the received ID Token.
Validation fails if no acr claim is present or the contained value does not match one of the requested acr values.
Validation succeeds if no acr values are requested or the value of the acr claim in the ID Token matches one of the requested acr values.

Disable to not validate the acr claim. In addition, it is possible to define custom acr validation using "Additional Claim Validators".

true

List of additional claim validators. Allows to validate the presence and value of specific claims. This can be useful to e.g. validate ID Token claims that were requested in an authorization request. See the configuration of "Claims To Request" and "ACR Values Claim".

If any of the validators fail, the ID Token is rejected and authorization fails.

Claim Validator

List of remote resources that are extracted from the OpenID Connect ID token.
An OAuth 2.0 credential containing data of these resources is instantiated. This credential can then be used by plugins such as OAuth 2.0 Credential Roles Provider and OAuth 2.0 Credential Context Data Map to provide the data from the Authorization Server to the ID Propagation. This enables the ability to propagate the data to the backends.

OAuth 2.0 Remote Context Data Resource OAuth 2.0 Remote User Role Resource OAuth 2.0 Remote Username Resource

The URL to which the AS should redirect after a logout has been performed.

It is recommended to define this property to ensure a seamless application flow. If not configured, the AS defines how to respond to the logout request.

OAuth 2.0 Post Logout Redirect Base URL OIDC No Post Logout Redirect URI

An identifier to identify the OAuth 2.0 Authorization Server or OpenID Provider.

OAuth 2.0 Provider Identifier

Defines the redirect URI (redirect_uri) parameter value to be included in OAuth 2.0 requests. The authorization response will then be sent to this URI by the authorization server (AS) or OpenID Provider (OP).

For redirects to the default IAM Loginapp UI use the "OAuth 2.0 Default UI Client Redirect URI".

OAuth 2.0 Custom Client Endpoint Redirect URI OAuth 2.0 Default UI Client Redirect URI OAuth 2.0 Legacy Client Endpoint Redirect URI OAuth 2.0 No Redirect URI

Resource requests that will be executed to determine the identity of the user on the provider.

An OAuth 2.0 credential containing data of these resources is instantiated. This credential can then be used by plugins such as OAuth 2.0 Credential Roles Provider and OAuth 2.0 Credential Context Data Map to provide the data from the Authorization Server to the ID Propagation. This enables the ability to propagate the data to the backends.

OAuth 2.0 SSO Resource Request

If enabled, this provider is available in the account linking self-service.

Users can link their IAM account with this provider to have an alternative authentication method.

The account link management is available for authenticated users under the Loginapp URL: <loginapp-uri>/ui/app/protected/account-links

OAuthAccountLinking,OAuthSocialRegistration

Account Linking Self Service

If configured, the flow will raise the configured red flag and continue in case no user could be identified using an account link.

This red flag can then be used by a following subflow to:

1. be triggered (by using Account Linking Required Red Flag Condition as condition for the subflow)
2. identify the local user with authentication steps
3. link the identified user to the provider account and take down the red flag (by using Missing Account Link Step as step in the subflow)

OAuthAccountLinking,OAuthSocialRegistration

Account Linking Required Red Flag Mandatory Password Change Red Flag Red Flag

Client ID identifying Airlock IAM at the authorization / token and resource endpoint of the OAuth 2.0 provider.
Only alphanumeric characters and '-_.' are allowed.

example-app

crypticyButUniqueAppId01953utjhu91823rih

Client secret used to verify the client.

HTTP method to use for Access Token requests.

OAuth 2.0 GET Request OAuth 2.0 POST Request

Custom OAuth 2.0 client logging behaviour for integration or error diagnostics.

OAuth 2.0 Logging Settings

If enabled, this provider will solely function as an alternative authentication method for the accounts of the Loginapp's user store. Meaning that users having an IAM account and an account link to a provider account can authenticate using this provider. Account links can be created by

• Users using the self-service
• The automated registration
• Auto-link feature

OAuthAccountLinking,OAuthSocialRegistration

false

If the provider's account has the same unique value for the given context data field as an existing account of the Loginapp's user persister, it will be linked with the provider's account. If left empty none of the existing accounts will be linked.

To be able to match the context data value, it is required to add an 'OAuth 2.0 Remote Context Data Resource' with a 'Local Context Data Key' equal to this value to the resource mappings and have a context data column entry equal to this value in the Loginapp's user persister.

If this feature is used in combination with 'Automated Account Registration', no accounts will be registered that have been auto-linked.

Security Warning: For security reasons this should always be a context data field that is globally unique (e.g. email or phone number) and was previously verified by the IAM registration process (channel verification) and the provider's registration process. If this is not guaranteed, an attacker may be able to use this feature to log into a victim's IAM account.

OAuthAccountLinking,OAuthSocialRegistration

email, mtan_number

Enables automated IAM account registration with data from this provider.

The user must always confirm the account registration.

If this feature is used in combination with 'Auto-link IAM Account Based on Context Data Field', no accounts will be registered that have been auto-linked.

Security Warning: For automated account registration, the provider's data is used without additional validation. In particular:

• Identity verification for mTAN numbers and/or email addresses is currently not supported.
• Data validation (e.g. using regular expressions) is currently not supported.
• The provider's data that is used to create the account is not displayed to the user and the user is not asked to confirm the data, e.g. using transaction approval.

Therefore, if this feature is used, the provider must guarantee that the provided data is valid (e.g. identity-verified and validated). IAM must trust the provider to do appropriate validation.

OAuthSocialRegistration

Automated Account Registration