Core settings
The core OpenID Connect provider / OAuth 2.0 authorisation server configuration is located in the properties file
WEB-INF/oidcProvider.properties
The configuration properties are grouped into sections:
- General settings
- Client registry
- Single sign-on (SSO)
- Pairwise subjects
- ID token
- Pushed authorisation endpoint (PAR)
- Authorisation endpoint
- Token endpoint
- Token introspection endpoint
- UserInfo endpoint
- Check session iframe
- Logout endpoint
- Back-channel logout
- Federation
- eKYC / identity assurance
- Mutual TLS
Any property in the configuration file can be overridden with a Java system property, e.g. by setting the optional -D argument at JVM startup:
-Dop.issuer=https://op.example.net
The external configuration guide has tips for setting system properties from environment variables, local files and other locations.
1. General
This group of properties sets the identifying URL of the OpenID provider / OAuth 2.0 authorisation server and the URLs for the privacy policy, the terms of service and the documentation for client application developers.
op.issuer
The URL identifying the OpenID provider / OAuth 2.0 authorisation server. The
issuer (iss
) claim in the ID and access tokens will be set to this URL.
Should be set to the base public URL of the Connect2id server and specify an
https schema.
Expected format:
[base-server-URL]
Example issuer URL:
op.issuer=https://openid.wonderland.net
op.issuerAliases
Optional issuer alias URLs of the OpenID provider / OAuth 2.0 authorisation server. Can be used to migrate from one issuer URL to another (op.issuer), or to operate an OpenID provider / OAuth 2.0 authorisation server known by multiple URLs.
An op.issuerAliases=*
property enables the HTTP reverse proxy to determine
the whitelisted issuer alias URLs, for deployments where issuer aliases must be
added or removed dynamically.
Leave blank if none.
Example with two issuer aliases:
op.issuerAliases.1=https://login.wonderland.net
op.issuerAliases.2=https://wonderland.net/sso
To enabling dynamic issuer alias addition and removal, the HTTP reverse proxy much check which URLs are allowed:
op.issuerAliases=*
op.issuerAliasMode
The issuer alias mode when issuer aliases of the OpenID provider / OAuth 2.0 authorisation server are enabled.
Supported modes:
- MIGRATION -- Enables seamless migration over time to a new issuer URL. This is the default mode.
- PERSISTED_GRANT_ISOLATION -- Enforces persisted grant isolation between issuer aliases: disables long-lived (persisted) consent; forces issue of self-contained (stateless) refresh tokens; blocks the use of any previously issued identifier-based refresh tokens.
op.issuerAliasMode=MIGRATION
op.policy
URL of the OpenID provider's / OAuth 2.0 authorisation server's policy regarding the relying parties' / clients' use of data, in human-readable form. The URL can be also be specified relative to the issuer URL. Leave blank if not specified.
Example policy URL:
op.policy=http://openid.wonderland.net/policy.html
op.tos
URL of the OpenID provider's / OAuth 2.0 authorisation server's terms of service, in human-readable form. The URL can be also be specified relative to the issuer URL. Leave blank if not specified.
Example terms of service URL:
op.tos=http://openid.wonderland.net/terms-of-service.html
op.serviceDocs
URL of the OpenID provider's / OAuth 2.0 authorisation server's service documentation for developers, in human-readable form. The URL can be also be specified relative to the issuer URL. Leave blank if not specified.
Example service documentation URL:
op.serviceDocs=http://openid.wonderland.net/service-docs.html
op.splashPage
The splash page to display at the Connect2id server issuer URL.
The default value is urn:c2id:splash_page:default
. Since v12.11.
Supported values:
- urn:c2id:splash_page:default -- The default splash page, an HTML page showing the Connect2id server version, a list of the available endpoints and links to public online documentation.
- urn:c2id:splash_page:blank -- A blank page.
- urn:c2id:splash_page:op_metadata -- Redirects (HTTP 301) to the OpenID
provider metadata at
/.well-known/openid-configuration
. - An https or http URL -- Redirects (HTTP 301) to the specified HTTPS or HTTP URL.
op.splashPage=urn:c2id:splash_page:default
op.customMetadata
Custom OpenID provider / OAuth 2.0 authorisation server
metadata to be included for publishing at the
.well-known/openid-configuration
and .well-known/oauth-authorization-server
endpoints. If set the metadata must be represented as a JSON object string
containing the custom fields, and can be additionally BASE64 encoded to ease
passing the configuration property from a command line shell.
Sample custom OpenID provider metadata:
op.customMetadata={"custom-param-1":"val-1","custom-param-2":"val-2"}
With additional BASE64 encoding:
op.customMetadata=eyJjdXN0b20tcGFyYW0tMSI6InZhbC0xLCJjdXN0b20tcGFyYW0tMiI6InZhbC0yfQ==
op.metadataOverlay
A JSON object overlay to apply to the OpenID provider / OAuth 2.0 authorisation
server metadata published at the
.well-known/openid-configuration
and .well-known/oauth-authorization-server
endpoints. Non-null values in the overlay object replace existing metadata
fields, null values remove them. Note, the overlay does not affect the internal
Connect2id server configuration and the resulting JSON object is not checked
for being a legal representation of OpenID provider / OAuth 2.0 authorisation
server metadata. If set the overlay must be represented as a JSON object
string, and can be additionally BASE64 encoded to ease passing the
configuration property from a command line shell. Since v12.18.
Sample overlay to hide the introspection endpoint:
op.metadataOverlay={"introspection_endpoint":null}
With additional BASE64 encoding:
op.metadataOverlay=eyJpbnRyb3NwZWN0aW9uX2VuZHBvaW50IjpudWxsfQ==
2. Client registry
The op.reg.*
group of properties sets the policy for
registering OAuth 2.0 / OpenID Connect clients.
op.reg.allowOpenRegistration
Enables / disables open (also called dynamic) registration of clients for the
authorization_code
, implicit
and refresh_token
grants. Open registration
is primarily intended for public Connect2id servers configured for automatic
OpenID provider discovery.
See the client registration reference for
more information.
Open registration is disabled by default for security reasons. If in doubt whether open registration should be enabled contact Connect2id support.
To prohibit open registration:
op.reg.allowOpenRegistration=false
op.reg.rejectNonTLSRedirectionURIs
Rejects / allows registration of non-TLS (plain HTTP and other unprotected)
redirection URIs in the authorisation code flow (response_type=code
).
Note that TLS (https) is always required for clients that register for the implicit flow.
To allow registration of plain http
redirection URIs in the code flow:
op.reg.rejectNonTLSRedirectionURIs=false
op.reg.allowLocalhostRedirectionURIsForTest
Allows registration of HTTP and HTTPS localhost redirection URIs for the purpose of testing and developing OAuth 2.0 web application clients. Must not be used in production!
The default value is false
(not allowed). Since v12.5.
To allow registration of web clients with a localhost redirection URI, such as
http://localhost:8008/login-callback
:
op.reg.allowLocalhostRedirectionURIsForTest=true
op.reg.enableProviderManagedSectorIDs
Enables / disables registration of OpenID provider managed sector identifiers
for the computation of pairwise subject (end-user) identifiers in issued ID
tokens and in UserInfo responses. A managed sector identifier can be registered
with the "sector_identifier_uri" set to a URN with the format
urn:c2id:sector_id:<id>
. The registration requires a master API token or a
one-time registration token with a client-reg:set-sector-id-urn
scope
value. The default value is false
(disabled). Since v12.0.
op.reg.enableProviderManagedSectorIDs=false
op.reg.accessTokenByteLength
The byte length of generated registration access tokens. Must be at least 32 bytes long to make brute force guessing impractical.
To set the length of generated registration access tokens to 32 bytes:
op.reg.accessTokenByteLength=32
op.reg.refreshAccessTokenOnUpdate
Enables / disables refreshing of the registration access token with each client registration update.
To disable refreshing of the client secret with client registration updates:
op.reg.refreshAccessTokenOnUpdate=true
op.reg.clientIDByteLength
The byte length of generated client identifiers. Must be at least 8 bytes long to provide a sufficiently large identifier space.
To set the length of generated client IDs to 8 bytes:
op.reg.clientIDByteLength=8
op.reg.clientSecretLifetime
The lifetime of issued client secrets, in hours. Zero means no expiration.
To make issued client secrets non-expiring:
op.reg.clientSecretLifetime=0
op.reg.alwaysRefreshClientSecretOnUpdate
Enables / disables refreshing of the client secret with each client
registration update. If false
the client secret will be refreshed only if it has expired.
To disable refreshing of the access token with client registration updates:
op.reg.alwaysRefreshClientSecretOnUpdate=false
op.reg.requestURIQuota
The maximum allowed number of registered request URIs (request_uris
).
The default value is 10.
op.reg.requestURIQuota=10
op.reg.requireInitialAccessTokenAudience
If true
the initial registration access token must include an audience value
that is the OpenID provider / OAuth 2.0 authorisation server issuer
URL or the client registration endpoint URL, else the access
token won't be accepted. The default value is true
.
op.reg.requireInitialAccessTokenAudience=true
op.reg.apiAccessTokenSHA256
Master access token for the entire client registration web API, represented by its SHA-256 hash (in hexadecimal format). The hashed storage is intended to prevent accidental leakage of the token through configuration files, logs, etc. The token is of type Bearer, non-expiring and must contain at least 32 random alphanumeric characters to make brute force guessing impractical. If not specified the web API will be disabled.
Additional access tokens, to facilitate token roll-over or for other needs,
can be configured by appending a dot (.) with a unique label to the property
name, e.g. as op.reg.apiAccessTokenSHA256.1=abc...
. Since v10.0.
The hash for a token with value ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6
:
op.reg.apiAccessTokenSHA256=cca68b8b82bcf0b96cb826199429e50cd95a042f8e8891d1ac56ab135d096633
op.reg.secondaryAPIAccessTokenSHA256
Optional secondary access token for the client registration web API. Has the same format as op.reg.apiAccessTokenSHA256. Must not be set if not needed.
Use op.reg.apiAccessTokenSHA256.*
from v10.0 on.
op.reg.secondaryAPIAccessTokenSHA256=304b07b6d8eb155a957b965831be9ce39fb098554a2d5f2047ee0a0491022dea
op.reg.resourceRetriever.httpConnectTimeout
The HTTP connect timeout (in milliseconds) for retrieving client resources (JWK sets and request objects specified by URI). Zero implies no timeout.
The default value is 250 ms.
op.reg.resourceRetriever.httpConnectTimeout=250
op.reg.resourceRetriever.httpReadTimeout
The HTTP read timeout (in milliseconds) for retrieving client resources (JWK sets and request objects specified by URI). Zero implies no timeout.
The default value is 250 ms.
op.reg.resourceRetriever.httpReadTimeout=250
op.reg.httpMaxRequestSize
Enforces a size limit on the entity body of HTTP POST and PUT requests to the client registration web API. Configurable via Java system property only! The default value is 250 thousand characters.
op.reg.httpMaxRequestSize=250000
3. Single sign-on (SSO)
The op.sso.*
properties configure the single sign-on policy.
op.sso.disableForSelectedClients
Disables single SSO for selected registered clients. Ensures end-users will be always (re)authenticated on the first OAuth 2.0 authorisation / OpenID authentication request when end-user has an existing session with the Connect2id server. Subsequent requests from the client received into the same end-user session will be processed as usual, without triggering re-authentication of the end-user.
Disabling SSO for a client creates the effect of "virtual" client-based sessions with the Connect2id server.
Clients with disabled SSO are selected by configuring a JSON query that accepts the client registration (as JSON object representation) and returns a boolean true result. The default configuration property is no selector specified.
Example configuration to disable SSO for clients with a data
JSON object in
their registration that contains a disable_sso:true
member:
op.sso.disableForSelectedClients=.data.disable_sso==true
4. Pairwise subjects
The op.pairwiseSubjects.*
properties configure the pairwise subject
identifier encoding.
op.pairwiseSubjects.padLocalSubjectsToLength
Enables output of pairwise subject identifiers with a uniform string length which is not affected by the length of the local (system) subject identifier. This measure is intended to prevent leaking information about the length of the local subject identifiers. Uniformity is achieved by padding local subject identifiers up to the specified length, which should be the maximum expected length of the local subjects. Subjects longer than the configured length will result in a pairwise encoding that is proportionally longer.
-1 (negative integer) disables padding.
Important note: Changing the padding length will reset all previously issued pairwise subject identifiers!
Since v12.0.
Example configuration for uniform encoding for an OpenID provider where the local user IDs have a length up to 50 characters:
op.pairwiseSubjects.padLocalSubjectsToLength=50
Configuration with disabled padding, to preserve any pairwise IDs issued in Connect2id server versions prior to v12.0:
op.pairwiseSubjects.padLocalSubjectsToLength=-1
5. ID token
The op.idToken.*
properties set the ID token preferences.
op.idToken.defaultLifetime
The default ID token lifetime, in seconds. Used to set the ID token expiration
time (exp
) after which the token must not be accepted by the client for
processing. Can be overridden by individual authorisations. Must be a positive
integer.
op.idToken.defaultLifetime=900
op.idToken.jwsAlgs
The enabled JWS algorithms for signing issued ID tokens.
Supported JWS algorithms:
- RS256
- RS384
- RS512
- PS256
- PS384
- PS512
- ЕS256
- ЕS256K
- ЕS384
- ЕS512
- HS256
- HS384
- HS512
- EdDSA
- none (use not recommended)
The algorithm RS256
must be always included. The value none
may be
included, but must not be used unless the response type used returns no ID
token from the authorisation endpoint (such as when using the authorisation
code flow).
The first JWS algorithm in the list becomes the default algorithm in client registrations.
To enable all supported JWS algorithms, save for none
, and make RS256
the
preferred one at client registration:
op.idToken.jwsAlgs=RS256,RS384,RS512,PS256,PS384,PS512,ES256,ES256K,ES384,ES512,HS256,HS384,HS512,EdDSA
op.idToken.jweAlgs
The enabled JWE key management algorithms for applying optional additional encryption to issued ID tokens.
Supported JWE algorithms:
- RSA-OAEP-256
- RSA-OAEP-384
- RSA-OAEP-512
- RSA-OAEP (use no longer recommended)
- RSA1_5 (use no longer recommended)
- ECDH-ES
- ECDH-ES+A128KW
- ECDH-ES+A192KW
- ECDH-ES+A256KW
- dir
- A128KW
- A192KW
- A256KW
- A128GCMKW
- A192GCMKW
- A256GCMKW
op.idToken.jweAlgs=RSA-OAEP-256,RSA-OAEP-384,RSA-OAEP-512,ECDH-ES,ECDH-ES+A128KW,ECDH-ES+A192KW,ECDH-ES+A256KW,dir,A128KW,A192KW,A256KW,A128GCMKW,A192GCMKW,A256GCMKW
op.idToken.jweEncs
The enabled JWE content encryption methods for applying optional additional encryption to issued ID tokens.
Supported JWE methods:
- A128CBC-HS256
- A192CBC-HS384
- A256CBC-HS512
- A128GCM
- A192GCM
- A256GCM
- XC20P
op.idToken.jweEncs=A128CBC-HS256,A192CBC-HS384,A256CBC-HS512,A128GCM,A192GCM,A256GCM,XC20P
op.idToken.includeStateHash
Enables / disables inclusion of a state hash claim (s_hash
) in issued ID
tokens. Disabled by default.
op.idToken.includeStateHash=false
op.idToken.includeJWTID
Enables / disables inclusion of a JWT
ID claim (jti
)
in issued ID tokens. Disabled by default. Since v12.1.
op.idToken.includeJWTID=false
op.idToken.ignoreUserInfoError
Specifies if ID tokens should be returned when the Connect2id server encounters an exception retrieving requested UserInfo claims for it. The recommended policy is to ignore such exceptions and always return an ID token.
op.idToken.ignoreUserInfoError=true
op.idToken.jwtType
The type ("typ") header of issued ID tokens. Explicit JWT typing is a simple measure to prevent mix-up of ID token JWTs with other types of JWT without having to examine the JWT claims structure. Note this is a non-standard feature and may result in rejection of ID tokens by client libraries not able or not configured to handle typing. Typing is disabled by default. Since v12.9.
Example explicit ID token typing:
op.idToken.jwtType=id_token+jwt
6. Pushed authorisation request (PAR)
op.par.lifetime
The lifetime of the pushed authorisation requests, in seconds. Must not be shorter than 10 seconds. The default value is 60 seconds.
op.par.lifetime=60
op.par.require
Enforces a global pushed authorisation request policy. If true
only pushed
authorisation requests will be accepted, regular and JAR authorisation
requests will be rejected at the authorisation endpoint with an
invalid_request
error. The default value is false
. Since v10.0.
op.par.require=false
7. Authorisation endpoint and login page integration
The op.authz.*
properties configure the OAuth 2.0 authorisation
endpoint and the web
interface for integrating the login page.
op.authz.endpoint
The OAuth 2.0 authorisation endpoint of the Connect2id server. Must be set to
the URL of the OpenID login page (hosted separately and bound to the Connect2id
server via the authorisation session API). The
URL schema should be https
. The URL can be also be specified relative to the
OpenID provider issuer URL. Leave blank if not specified.
op.authz.endpoint=https://openid.wonderland.net/login
op.authz.apiAccessTokenSHA256
The access token for the authorisation session endpoint, represented by its SHA-256 hash (in hexadecimal format). The hashed storage is intended to prevent accidental leakage of the token through configuration files, logs, etc. The token is of type Bearer, non-expiring and must contain at least 32 random alphanumeric characters to make brute force guessing impractical.
Additional access tokens, to facilitate token roll-over or for other needs,
can be configured by appending a dot (.) with a unique label to the property
name, e.g. as op.authz.apiAccessTokenSHA256.1=abc...
. Since v10.0.
The hash for a token with value ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6
:
op.authz.apiAccessTokenSHA256=cca68b8b82bcf0b96cb826199429e50cd95a042f8e8891d1ac56ab135d096633
op.authz.sessionLifetime
The authorisation session lifetime, in minutes.
op.authz.sessionLifetime=15
op.authz.responseTypes
The enabled OAuth 2.0 response_type
values, separated by comma.
Supported OAuth 2.0 and OpenID Connect response types:
- code
- token
- id_token
- id_token token
- code id_token
- code id_token token
At a minimum code
must be included.
To enable all supported response types:
op.authz.responseTypes=code,token,id_token,id_token token,code id_token,code id_token token
op.authz.responseModes
The enabled OAuth 2.0 response_mode
values.
Supported standard response modes:
- query
- fragment
- form_post
- query.jwt
- fragment.jwt
- form_post.jwt
- jwt
The list may include custom (non-standard, experimental) response modes, such
as based on CORS Ajax or window.postMessage
provided the authorisation
session handler (the login page) is able to
support them.
At a minimum query
and fragment
must be included.
op.authz.responseModes=query,fragment,form_post,query.jwt,fragment.jwt,form_post.jwt,jwt
op.authz.prohibitSwitchBetweenBasicResponseModes
If true
client requests to switch between the query
and fragment
response
modes by setting the response_mode
authorisation request parameter are
prohibited. The default value is false
. Since v9.5.
op.authz.prohibitSwitchBetweenBasicResponseModes=false
op.authz.requestJWSAlgs
The accepted JWS algorithms for signed OAuth 2.0 authorisation requests (JAR)
passed with the optional request_uri
or request
parameter.
Supported JWS algorithms:
- HS256
- HS384
- HS512
- RS256
- RS384
- RS512
- PS256
- PS384
- PS512
- ES256
- ES256K
- ES384
- ES512
- none (use not recommended)
The first JWS algorithm in the list becomes the default algorithm in client registrations.
op.authz.requestJWSAlgs=HS256,HS384,HS512,RS256,RS384,RS512,PS256,PS384,PS512,ES256,ES256K,ES384,ES512
op.authz.requestJWEAlgs
The accepted JWE algorithms for encrypted OAuth 2.0 authorisation requests
(JAR) passed with the optional request_uri
or request
parameter.
Supported JWE algorithms:
- RSA-OAEP-256
- RSA-OAEP-384
- RSA-OAEP-512
- RSA-OAEP (use no longer recommended)
- RSA1_5 (use no longer recommended)
- ECDH-ES
- ECDH-ES+A128KW
- ECDH-ES+A192KW
- ECDH-ES+A256KW
- dir
op.authz.requestJWEAlgs=RSA-OAEP-256,RSA-OAEP-384,RSA-OAEP-512,ECDH-ES,ECDH-ES+A128KW,ECDH-ES+A192KW,ECDH-ES+A256KW,dir
op.authz.requestJWEEncs
The accepted JWE content encryption methods for encrypted OAuth 2.0
authorisation requests (JAR) passed with the optional request_uri
or
request
parameter.
Supported JWE methods:
- A128CBC-HS256
- A192CBC-HS384
- A256CBC-HS512
- A128GCM
- A192GCM
- A256GCM
- XC20P
op.authz.requestJWEEncs=A128CBC-HS256,A192CBC-HS384,A256CBC-HS512,A128GCM,A192GCM,A256GCM,XC20P
op.authz.responseJWSAlgs
The accepted JWS algorithms for signed OAuth 2.0 authorisation responses
(JARM). RS256 is the default algorithm when a client explicitly requests a
JWT-secured authorisation response by means of the response_mode
request
parameter and isn't registered for a specific JWS algorithm. If RS256
isn't
in the list of supported algorithms then the first in the list will apply.
Since v11.0.
Supported JWS algorithms:
- HS256
- HS384
- HS512
- RS256
- RS384
- RS512
- PS256
- PS384
- PS512
- ES256
- ES256K
- ES384
- ES512
- EdDSA
op.authz.responseJWSAlgs=HS256,HS384,HS512,RS256,RS384,RS512,PS256,PS384,PS512,ES256,ES256K,ES384,ES512,EdDSA
op.authz.responseJWEAlgs
The accepted JWE algorithms for encrypted OAuth 2.0 authorisation responses (JARM). Note, encryption is always applied after signing. Since v11.0.
Supported JWE algorithms:
- RSA-OAEP-256
- RSA-OAEP-384
- RSA-OAEP-512
- RSA-OAEP (use no longer recommended)
- RSA1_5 (use no longer recommended)
- ECDH-ES
- ECDH-ES+A128KW
- ECDH-ES+A192KW
- ECDH-ES+A256KW
- dir
op.authz.responseJWEAlgs=RSA-OAEP-256,RSA-OAEP-384,RSA-OAEP-512,ECDH-ES,ECDH-ES+A128KW,ECDH-ES+A192KW,ECDH-ES+A256KW,dir
op.authz.responseJWEEncs
The accepted JWE content encryption methods for encrypted OAuth 2.0 authorisation responses (JARM). Since v11.0.
Supported JWE methods:
- A128CBC-HS256
- A192CBC-HS384
- A256CBC-HS512
- A128GCM
- A192GCM
- A256GCM
- XC20P
op.authz.responseJWEEncs=A128CBC-HS256,A192CBC-HS384,A256CBC-HS512,A128GCM,A192GCM,A256GCM,XC20P
op.authz.includeClientInfoInAuthPrompt
If true
the Connect2id server will include the registered OAuth 2.0 / OpenID
client information in the authentication
prompt. The client details can then
be used as an additional input to the determine the appropriate end-user
authentication or
session settings.
The client information is required typically only at the consent step (implies
false
).
op.authz.includeClientInfoInAuthPrompt=false
op.authz.includeClientInfoInFinalResponse
If true
the Connect2id server will include the registered OAuth 2.0 / OpenID
Connect client information in the final
response of an authorisation session.
The client information is required typically only at the consent step (implies
false
).
op.authz.includeClientInfoInFinalResponse=false
op.authz.includeSubjectSessionInFinalResponse
If true
the Connect2id server will include the subject (end-user)
session with its ID and other
parameters in the final
response of an authorisation session as
well as in non-redirecting errors.
The subject session is required typically only when a UI is presented, during
authentication and consent (implies false
).
op.authz.includeSubjectSessionInFinalResponse=false
op.authz.includeOtherConsentedScopeAndClaimsInPrompt
If true
the Connect2id server will include non-requested scope values and
claim names for which previous consent exists in the consent
prompt.
If false
only those scope values and claim names that are explicitly
requested by the client will be included in the consent
prompt.
op.authz.includeOtherConsentedScopeAndClaimsInPrompt=false
op.authz.includeRawClaimsRequestInPrompt
If true
the Connect2id server will include in the raw OpenID "claims" request
parameter in the consent prompt.
The default value is false
. Since v8.0.
op.authz.includeRawClaimsRequestInPrompt=false
op.authz.requestParamsInAuthPrompt
Names of selected OAuth 2.0 authorisation request parameters to include in the authentication prompt. No parameters are included by default. Since v11.6.
To include the scope
and resource
parameter values:
op.authz.requestParamsInAuthPrompt=scope,resource
op.authz.requestParamsInConsentPrompt
Names of selected OAuth 2.0 authorisation request parameters to include in the consent prompt. No parameters are included by default. Since v11.6.
To include some custom parameter values:
op.authz.requestParamsInConsentPrompt=custom-x,custom-y,custom-z
op.authz.alwaysPromptForAuth
The Connect2id server is normally configured (false
) to always skip the
authentication step, provided the end-user has a valid session (established by
a cookie) and the authentication strength requirement (ACCR) of the client are
met.
If true
the Connect2id server will act as if the client set a
prompt=login authorisation request
parameter. It will always prompt for
authentication, even if the
end-user is currently authenticated (has a valid session). This can be used to
ensure some custom logic or script is always executed during the authentication
step. OpenID prompt=none
authentication requests will be handled according to
op.authz.alwaysPromptMode.
op.authz.alwaysPromptForAuth=false
op.authz.alwaysPromptForConsent
The Connect2id server is normally configured (false
) to always skip the
consent step, provided such is already recorded for the given end-user and
client.
If true
the Connect2id server will act as if the client set a
prompt=consent authorisation request
parameter. It will always prompt for
consent, even if previous
consent for the end-user and client exists. This can be used to ensure some
custom logic or script is always executed during the consent step. OpenID
prompt=none
authentication requests will be handled according to
op.authz.alwaysPromptMode.
op.authz.alwaysPromptForConsent=false
op.authz.alwaysPromptMode
Controls processing of OpenID prompt=none
authentication requests when
op.authz.alwaysPromptForAuth or
op.authz.alwaysPromptForConsent is enabled.
Supported modes:
- LIMITED -- No authentication or consent prompt will be returned on a OpenID
prompt=none
authentication request. The Connect2id server will proceed straight to returning the final response (success orlogin_required
/consent_required
error). - PROMPT_NONE -- An authentication or consent prompt will be returned on a
OpenID
prompt=none
authentication request provided an existing session or consent is found and the request can be fulfilled with no end-user interaction. This is the default mode for legacy reasons. - PROMPT_NONE_WITH_INTERACTION_ERRORS -- An authentication or consent prompt
will be returned on a OpenID prompt=none authentication request even if the
request cannot be fulfilled due to required end-user interaction; in that
case the login page must handle the
login_required
andconsent_required
errors by itself.
op.authz.alwaysPromptMode=PROMPT_NONE
op.authz.alwaysRequireRedirectURI
If true
the redirect_uri
parameter will be required for all authorisation
requests, not only for OpenID authentication requests. The default value is
false
(required only for OpenID authentication requests).
op.authz.alwaysRequireRedirectURI=false
op.authz.allowedPKCE
The allowed PKCE (RFC 7636) code
challenge methods which OAuth 2.0 clients may use at the authorisation
endpoint, as comma and / or space separated list. The default allowed code
challenge methods are plain
and S256
. Since v10.3.
Supported PKCE methods:
- plain
- S256
op.authz.allowedPKCE=plain,S256
op.authz.requiredPKCE
The required PKCE (RFC 7636) code challenge methods which OAuth 2.0 clients must use at the authorisation endpoint, as comma and / or space separated list. If empty or omitted PKCE is not required.
Supported methods:
- plain
- S256
op.authz.requiredPKCE=S256
op.authz.requireIDTokenHintWithPromptNone
Specifies if a valid ID token hint (id_token_hint
) parameter is required for
prompt=none authorisation requests.
To accept prompt=none
requests without an ID token hint:
op.authz.requireIDTokenHintWithPromptNone=false
op.authz.oAuthRequestJWTPolicy
The policy for merging unsecured parameters in a JWT-secured OAuth 2.0
authorisation request (JAR) (excluding OpenID
authentication requests). Also applies to Pushed Authorisation Requests (PAR):
JAR requests submitted to the PAR endpoint and PAR request_uri
s
in authorisation requests. Since v9.2.
Supported policies:
- STRICT -- Use only JWT-secured parameters, unsecured query parameters will be ignored. This is the default policy for OAuth 2.0 authorisation requests.
- MERGE_UNSECURED -- Merge unsecured authorisation request query parameters, with the JWT-secured parameters having precedence.
op.authz.oAuthRequestJWTPolicy=STRICT
op.authz.openIDRequestJWTPolicy
The policy for merging unsecured parameters in a JWT-secured OpenID
authentication request. Also applies to Pushed
Authorisation Requests (PAR): JWT-secured requests submitted to the PAR
endpointand PAR request_uri
s in authentication requests. Since
v9.2.
Supported policies:
- STRICT -- Use only JWT-secured parameters, unsecured query parameters will be ignored.
- MERGE_UNSECURED -- Merge unsecured OpenID authentication request query parameters, with the JWT-secured parameters having precedence. This is the default policy for OpenID authentication requests.
op.authz.openIDRequestJWTPolicy=MERGE_UNSECURED
op.authz.alwaysRequireSignedRequestJWT
If true
a JWS signed request JWT passed inline via request
or by URL
reference via request_uri
will be required for all authorisation requests,
including pushed authorisation requests (PAR). The default value is false
(not required unless the client is explicitly registered for it). Since v11.6.
op.authz.alwaysRequireSignedRequestJWT=false
op.authz.requireRequestJWTExpiration
If true
received request JWTs must include an expiration (exp
) claim. The
default value is false
.
op.authz.requireRequestJWTExpiration=false
op.authz.requireRequestJWTNotBefore
If true
received request JWTs must include a not before (nbf
) claim. The
default value is false
. Since v11.6.
op.authz.requireRequestJWTNotBefore=false
op.authz.maxLifetimeRequestJWTExpiration
The maximum accepted lifetime in seconds of an expiration (exp
) claim in
request JWTs. The lifetime is computed from the not before (nbf
) claim if
present, otherwise from the current time. The default value is -1
(not
specified). Since v11.6.
op.authz.maxLifetimeRequestJWTExpiration=-1
op.authz.maxAgeRequestJWTNotBefore
The maximum accepted age in seconds of a not before (nbf
) claim in request
JWTs. The default value is -1
(not specified). Since v11.6.
op.authz.maxAgeRequestJWTNotBefore=-1
op.authz.requireAllParamsInRequestJWT
If true
received request JWTs must cover all authorisation request
parameters, those with unsecured parameters will be rejected with an
invalid_request
error. The default value is false
.
op.authz.requireAllParamsInRequestJWT=false
op.authz.alwaysRequireSignedResponse
If true
all authorisation requests must specify a JWT-secured response (JARM)
or a response_type
that includes an id_token
to serve as a detached
signature. The default value is false
. Since v11.6.
op.authz.alwaysRequireSignedResponse=false
op.authz.feedSubjectSessionClaimsIntoIDToken
If true
claims stored in the subject (end-user)
session will be automatically
fed as additional claims into the issued ID tokens (for all clients). Applies
to regular as well as prompt=none
OpenID authentication requests.
op.authz.feedSubjectSessionClaimsIntoIDToken=true
op.authz.customErrorCodes
Additional custom OAuth 2.0 error codes allowed to be returned at the authorisation endpoint, as a space / comma separated list.
The default setting is no custom error codes.
op.authz.customErrorCodes=
op.authz.advertisedScopes
The supported OAuth 2.0 scope values to advertise in the OpenID
provider / OAuth 2.0 authorisation server metadata (for service discovery). The
openid
scope value must be always included. The standard OpenID scope values
should be included if supported. Other scope values that are custom or
application-specific may not be advertised.
To advertise support of all standard OpenID scope values:
op.authz.advertisedScopes=openid,profile,email,address,phone,offline_access
op.authz.advertisedClaims
The supported OpenID claim (standard and custom) to advertise in the OpenID
provider metadata (for service discovery). The sub
(subject / user
identifier) claim name must be always included. Note that for privacy or other
reasons this might not be an exhaustive list.
Example claims to advertise:
op.authz.advertisedClaims=sub,iss,auth_time,acr,name,given_name,family_name,nickname,email,email_verified
op.authz.advertisedACRs
The supported Authentication Context Class References, also called levels of assurance (LoA) to advertise in the OpenID provider metadata (for service discovery). Leave empty if none.
Important: For proper step-up authentication, order the ACRs from lowest to highest (basic to high).
Example list of two supported ACRs:
op.authz.advertisedACRs=https://loa.c2id.com/lowsec,https://loa.c2id.com/highsec
op.authz.advertisedDisplayTypes
The supported display
parameter values to advertise in the OpenID provider
metadata (for service discovery).
Standard display values:
- page
- popup
- touch
- wap
To advertise support of page
and popup
display types:
op.authz.advertisedDisplayTypes=page,popup
op.authz.advertisedUILocales
The supported languages and scripts for the user interface, represented as BCP47 (RFC 5646) language tag values, to advertise in the OpenID provider metadata (for service discovery).
To advertise UI support of English, Spanish and German language:
op.authz.advertisedUILocales=en,es,de
8. Token Endpoint
The op.token.*
properties set the accepted client authentication methods at
the token endpoint.
op.token.authMethods
The enabled client authentication methods at the token endpoint. The first method in the list specifies the default for clients that don't specify one explicitly during registration.
The tls_client_auth
and self_signed_tls_client_auth
methods are mutually
exclusive and cannot be enabled simultaneously.
Supported authentication methods:
- client_secret_basic -- Basic authentication
with the
client_secret
passed in the Authorization header. - client_secret_post -- Basic authentication
with the
client_secret
passed in the request body as form parameters. - client_secret_jwt -- JWT authentication
using the
client_secret
as shared HMAC key. - private_key_jwt -- JWT authentication using public RSA or EC cryptography; the client must register its public key (s) with the Connect2id server.
- tls_client_auth -- PKI client authentication; the client must include a CA-issued client X.509 certificate in requests.
- self_signed_tls_client_auth -- Self-signed client X.509 certificate authentication; the client must register its public key(s) for the certificate with the Connect2id server.
- none -- No client authentication.
The none
method enables public (unauthenticated) clients.
op.token.authMethods=client_secret_basic,client_secret_post,client_secret_jwt,private_key_jwt,self_signed_tls_client_auth,none
To allow only mTLS authentication with self-signed client X.509 certificates:
op.token.authMethods=self_signed_tls_client_auth
op.token.authJWSAlgs
The enabled JWS algorithms for client_secret_jwt
and private_key_jwt
client authentication at the token endpoint. It is
suggested that all supported algorithms are enabled.
Supported JWS algorithms:
For
client_secret_jwt
authentication: HS256, HS384, HS512For
private_key_jwt
authentication : RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES256K, ES384, ES512
To enable all supported JWS algorithms for client_secret_jwt
and
private_key_jwt
client authentication:
op.token.authJWSAlgs=HS256,HS384,HS512,RS256,RS384,RS512,PS256,PS384,PS512,ES256,ES384,ES512
op.token.requireClientX509Cert
If true
the token endpoint will require a client X.509 certificate from all
clients, in order to enforce issue of client certificate bound access tokens
(RFC 8705). The default value is false
. Since v9.5.
op.token.requireClientX509Cert=false
9. Token Introspection Endpoint
The op.token.introspection.*
properties configure the token introspection
endpoint.
op.token.introspection.pruneAudience
If true
causes the audience (aud
) in token introspection responses to be
pruned to the client_id
of the introspecting client, intended to prevent
revealing information about recipients other than the intended in
multi-audience tokens. If false
the complete token audience will be shown.
Has no effect on tokens that don't specify an audience. The default value is
true
. Since 13.1.
To disable audience pruning:
op.token.introspection.pruneAudience=false
op.token.introspection.alwaysRespondWithJWT
If true
causes the token introspection responses to be always returned as a
JWT signed with the same JWS algorithm
and key as self-contained (JWT) access tokens. The default value is false
.
op.token.introspection.alwaysRespondWithJWT=false
op.token.introspection.jwtType
The type (typ
) header of JWT introspection responses. The default value is
token-introspection+jwt
. This configuration enables the type header to be
set to JWT
for non-compliant clients and JWT libraries which cannot handle
header values other than JWT
. Since v9.0.
op.token.introspection.jwtType=token-introspection+jwt
10. UserInfo Endpoint
The op.userinfo.*
properties configure the UserInfo
endpoint.
op.userinfo.jwsAlgs
The enabled JWS algorithms for signing issued UserInfo JWTs.
Supported JWS algorithms:
- RS256
- RS384
- RS512
- PS256
- PS384
- PS512
- ES256
- ES256K
- ES384
- ES512
- HS256
- HS384
- HS512
- EdDSA
Tp enable all supported JWS algorithms:
op.userinfo.jwsAlgs=RS256,RS384,RS512,PS256,PS384,PS512,ES256,ES256K,ES384,ES512,HS256,HS384,HS512,EdDSA
op.userinfo.jweAlgs
The enabled JWE key management algorithms for applying optional additional encryption to issued UserInfo JWTs.
Supported JWE algorithms:
- RSA-OAEP-256
- RSA-OAEP-384
- RSA-OAEP-512
- RSA-OAEP (use no longer recommended)
- RSA1_5 (use no longer recommended)
- ECDH-ES
- ECDH-ES+A128KW
- ECDH-ES+A192KW
- ECDH-ES+A256KW
- dir
- A128KW
- A192KW
- A256KW
- A128GCMKW
- A192GCMKW
- A256GCMKW
op.userinfo.jweAlgs=RSA-OAEP-256,RSA-OAEP-384,RSA-OAEP-512,ECDH-ES,ECDH-ES+A128KW,ECDH-ES+A192KW,ECDH-ES+A256KW,dir,A128KW,A192KW,A256KW,A128GCMKW,A192GCMKW
op.userinfo.jweEncs
The enabled JWE content encryption methods for applying optional additional encryption to issued UserInfo JWTs.
Supported JWE methods:
- A128CBC-HS256
- A192CBC-HS384
- A256CBC-HS512
- A128GCM
- A192GCM
- A256GCM
- XC20P
op.userinfo.jweEncs=A128CBC-HS256,A192CBC-HS384,A256CBC-HS512,A128GCM,A192GCM,A256GCM,XC20P
op.userinfo.allowAccessTokenInURIQuery
If true
the UserInfo endpoint will allow access tokens submitted via the
access_token
URI query parameter. The default policy (false
) is to reject
access tokens received via the URI query parameter in order to prevent
potential token leakage via web server access logs. The URI query method
should not be allowed unless it is impossible to transport the access token
in the "Authorization" request header field or the HTTP request entity-body.
op.userinfo.allowAccessTokenInURIQuery=false
op.userinfo.jwtType
The type ("typ") header of issued UserInfo JWTs. Explicit JWT typing is a simple measure to prevent mix-up of UserInfo JWTs with other types of JWT without having to examine the JWT claims structure. Note this is a non-standard feature and may result in rejection of UserInfo JWTs by client libraries not able or not configured to handle typing. Typing is disabled by default. Since v12.9.
Example explicit UserInfo JWT typing:
op.userinfo.jwtType=userinfo+jwt
11. Check Session Iframe
The op.checkSession.*
properties configure the OpenID check
session iframe.
op.checkSession.iframe
The OpenID Connect check session iframe URL. The URL schema should be https
.
The URL can be also be specified relative to the OpenID provider issuer
URL.
Browser JavaScript code running in the iframe must be able to access the
cookie used to store the subject (end-user)
session ID. This requires the iframe to have the same web
origin (domain) as the login page which
set the session cookie. The cookie must also be set with a path visible by the
iframe and without the HttpOnly
flag.
If blank check session support will be disabled and the iframe will not be advertised in the OpenID provider metadata.
The Connect2id server provides a default check session iframe at
/check-session.html
relative to the OpenID provider issuer URL.
op.checkSession.iframe=/check-session.html
op.checkSession.cookieName
The name of the cookie which is used by the login page to store the subject
(end-user) session ID. The cookie must be accessible from browser JavaScript
running in the check session iframe, i.e. it must be
set with a common path and without the HttpOnly
flag.
op.checkSession.cookieName=sid
12. Logout (End-Session) Endpoint
The op.logout.*
properties configure the OpenID logout (end-session)
endpoint and the web interface
for integrating the logout page.
op.logout.endpoint
The OpenID Connect Logout (end-session) endpoint of the Connect2id server. Must
be set to the URL of the OpenID provider logout page (hosted separately from
the Connect2id server). The URL schema should be https
. The URL can also be
specified relative to the OpenID provider issuer URL. Leave blank
if not specified.
If blank the endpoint will be disabled and not advertised in the OpenID provider metadata. OpenID relying party initiated logout requests will be refused.
op.logout.endpoint=https://oidc.wonderland.net/logout
op.logout.apiAccessTokenSHA256
The access token for the logout session endpoint, represented by its SHA-256 hash (in hexadecimal format). The hashed storage is intended to prevent accidental leakage of the token through configuration files, logs, etc. The token is of type Bearer, non-expiring and must contain at least 32 random alphanumeric characters to make brute force guessing impractical.
Additional access tokens, to facilitate token roll-over or for other needs,
can be configured by appending a dot (.) with a unique label to the property
name, e.g. as op.logout.apiAccessTokenSHA256.1=abc...
. Since v10.0.
The hash for a token with value ztucZS1ZyFKgh0tUEruUtiSTXhnexmd6
:
op.logout.apiAccessTokenSHA256=cca68b8b82bcf0b96cb826199429e50cd95a042f8e8891d1ac56ab135d096633
op.logout.sessionLifetime
The logout session lifetime, in minutes.
op.logout.sessionLifetime=5
13. Back-channel Logout
The op.logout.backChannel.*
properties configure the back-channel logout
tokens and their dispatch.
op.logout.backChannel.jwtTypeExplicit
If true
logout tokens will be explicitly typed with a JWT type ("typ") header
header set to "logout+jwt". Explicit JWT typing is a simple measure to prevent
mix-up of logout token JWTs with other types of JWT without having to examine
the JWT claims structure. Enabled by default. Since v12.10.
op.logout.backChannel.jwtTypeExplicit=true
op.logout.backChannel.httpConnectTimeout
The HTTP connect timeout (in milliseconds) for posting a logout token. Zero means no timeout. Must not be negative. The default value is 250 ms.
op.logout.backChannel.httpConnectTimeout=250
op.logout.backChannel.httpReadTimeout
The HTTP read timeout (in milliseconds) for posting a logout token. Zero means no timeout. Must not be negative. The default value is 250 ms.
op.logout.backChannel.httpReadTimeout=250
14. Federation
Settings for OpenID Connect Federation 1.0. A server participating in a federation must also be provisioned with a key for signing the issued entity statements.
op.federation.enable
Enables / disables OpenID Connect Federation 1.0. Disabled by default.
op.federation.enable=false
op.federation.clientRegistrationTypes
The enabled OpenID Connect Federation 1.0 client registration types.
Supported client registration types:
- explicit
- automatic
op.federation.clientRegistrationTypes=explicit,automatic
op.federation.autoClientAuthMethods.ar
The enabled methods for authenticating OpenID Connect Federation 1.0 automatic client registration requests at the OAuth 2.0 authorisation endpoint.
Supported methods:
- request_object
op.federation.autoClientAuthMethods.ar=request_object
op.federation.autoClientAuthMethods.par
The enabled methods for authenticating OpenID Connect Federation 1.0 automatic client registration requests at the OAuth 2.0 pushed authorisation request (PAR) endpoint. Since 13.1.
Supported methods:
- private_key_jwt
- tls_client_auth
- self_signed_tls_client_auth
op.federation.autoClientAuthMethods.par=private_key_jwt,tls_client_auth,self_signed_tls_client_auth
op.federation.organizationName
The organisation name in the federation. Leave blank if not specified.
op.federation.organizationName=
op.federation.trustAnchors
The configured trust anchors. Must contain at least one entity ID.
Example with one configured trust anchor:
op.federation.trustAnchors.1=https://federation.example.com
Example with multiple configured trust anchors:
op.federation.trustAnchors.1=https://university-federation.example.com
op.federation.trustAnchors.2=https://partners-federation.example.com
op.federation.trustAnchors.3=https://eid-federation.example.com
op.federation.authorityHints
The trust anchors or intermediate entities that may issue an entity statement about this OpenID Connect provider. Must contain at least one entity ID.
Example with one authority which is also the trust anchor:
op.federation.authorityHints.1=https://federation.example.com
Example with two authorities:
op.federation.authorityHints.1=https://company.example.com
op.federation.authorityHints.2=https://local-companies-authority.example.com
op.federation.constraints.maxPathLength
The maximum path length when resolving trust chains. The default value is 2 (up to two intermediates to the trust anchor).
op.federation.constraints.maxPathLength=2
op.federation.constraints.permitted
The explicitly permitted entity IDs when resolving trust chains. Leave blank if not specified.
op.federation.constraints.permitted.1=
op.federation.constraints.permitted.2=
op.federation.constraints.permitted.3=
op.federation.constraints.excluded
The excluded entity IDs when resolving trust chains. Leave blank if not specified.
op.federation.constraints.excluded.1=
op.federation.constraints.excluded.2=
op.federation.constraints.excluded.3=
op.federation.httpRequestTimeout
The HTTP read timeout (in milliseconds) when resolving trust chains. Zero implies no timeout. Must not be negative. The default value is 500 ms.
op.federation.httpRequestTimeout=500
op.federation.httpReadTimeout
The HTTP read timeout (in milliseconds) when resolving trust chains. Zero implies no timeout. Must not be negative. The default value is 500 ms.
op.federation.httpReadTimeout=500
op.federation.contacts
List of contacts for this federation entity. These may contain names, e-mail addresses, descriptions, phone numbers, etc. Leave blank if not specified.
[email protected]
[email protected]
op.federation.contacts.3=+19945006700
op.federation.logoURI
URL of the federation entity logo. The URL can be also specified relative to the issuer URL. Leave blank if not specified. Since 13.1.
op.federation.logoURI=
op.federation.policyURI
URL of the federation entity policy. The URL can be also specified relative to the issuer URL. Leave blank if not specified.
op.federation.policyURI=
op.federation.homepageURI
URL of the federation entity homepage. The URL can be also specified relative to the issuer URL. Leave blank if not specified.
op.federation.homepageURI=
op.federation.trustMarks
Trust marks about this federation entity as signed JSON Web Tokens (JWT). Leave blank if not specified.
op.federation.trustMarks.1=
op.federation.trustMarks.2=
op.federation.trustMarks.3=
op.federation.entityStatementLifetime
The lifetime of issued entity statements, in seconds. The default lifetime is one week (604800 seconds).
op.federation.entityStatementLifetime=604800
op.federation.autoClientLifetime
The lifetime of registered OpenID Connect Federation 1.0 automatic clients, in seconds. If zero or negative the lifetime will be determined by the trust chain expiration time. When explicitly set must not be shorter than 5 minutes (300 seconds) to allow sufficient time for the completion of a single OAuth 2.0 flow with an authorisation, token and UserInfo request by the registered relying party. The default lifetime is one hour (3600 seconds).
op.federation.autoClientLifetime=3600
15. Identity assurance
Settings for OpenID Connect for Identity Assurance 1.0.
op.assurance.supportsVerifiedClaims
Enables / disables advertisement for OpenID Connect for Identity Assurance
1.0 support in OpenID provider
metadata and enables Connect2id server processing
of verified claims. Corresponds to the verified_claims_supported
OpenID
provider metadata parameter. Disabled by default.
op.assurance.supportsVerifiedClaims=true
op.assurance.supportedTrustFrameworks
The supported trust frameworks if OpenID Connect for Identity Assurance 1.0
support is enabled. Corresponds to the trust_frameworks_supported
OpenID
provider metadata parameter.
Example:
op.assurance.supportedTrustFrameworks=eidas,nist_800_63A
op.assurance.supportedIdentityEvidenceTypes
The supported identity evidence types if OpenID Connect for Identity
Assurance 1.0 support is enabled. Corresponds to the evidence_supported
OpenID provider metadata parameter.
Example:
op.assurance.supportedIdentityEvidenceTypes=document,electronic_signature,electronic_record
op.assurance.supportedDocumentTypes
The supported document types if OpenID Connect for Identity Assurance 1.0
support is enabled. Corresponds to the documents_supported
OpenID provider
metadata parameter. Since v12.6.
Example:
op.assurance.supportedDocumentTypes=idcard,passport,utility_statement
op.assurance.supportedIDDocumentTypes
The supported ID document types if OpenID Connect for Identity Assurance 1.0
support is enabled. Corresponds to the id_documents_supported
OpenID
provider metadata parameter. Deprecated in
v12.6.
op.assurance.supportedIDDocumentTypes=idcard,passport,driving_permit
op.assurance.supportedIdentityVerificationMethods
The supported identity verification methods if OpenID Connect for Identity
Assurance 1.0 support is enabled. Corresponds to the
id_documents_verification_methods_supported
OpenID provider
metadata parameter. Deprecated in v12.6.
op.assurance.supportedIdentityVerificationMethods=pipp,sripp,eid
op.assurance.supportedMethodsForDocuments
The supported coarse identity verification methods for
evidences of type
document if OpenID Connect for Identity Assurance 1.0 support is enabled.
Corresponds to the documents_methods_supported
OpenID provider
metadata parameter. Since v12.6.
Example:
op.assurance.supportedMethodsForDocuments=pipp,sripp
op.assurance.supportedValidationMethodsForDocuments
The supported validation methods for
evidences of type document if
OpenID Connect for Identity Assurance 1.0 support is enabled. Corresponds to
the documents_validation_methods_supported
OpenID provider
metadata parameter. Since v12.6.
Example:
op.assurance.supportedValidationMethodsForDocuments=vpip,vpiruv,vri
op.assurance.supportedVerificationMethodsForDocuments
The supported person verification methods for
evidences of type document if
OpenID Connect for Identity Assurance 1.0 support is enabled. Corresponds to
the documents_verification_methods_supported
OpenID provider
metadata parameter. Since v12.6.
Example:
op.assurance.supportedVerificationMethodsForDocuments=pvr,pvp
op.assurance.supportedElectronicRecordTypes
The supported electronic record types if OpenID Connect for Identity
Assurance 1.0 support is enabled. Corresponds to the
electronic_records_supported
OpenID provider
metadata parameter. Since v12.6.
Example:
op.assurance.supportedElectronicRecordTypes=population_register,bank_account
op.assurance.supportedVerifiedClaims
The supported verified claims if OpenID Connect for Identity Assurance 1.0
support is enabled. Corresponds to the claims_in_verified_claims_supported
OpenID provider metadata parameter.
op.assurance.supportedVerifiedClaims=given_name,family_name,birthdate,birthplace,address
op.assurance.supportedAttachments
The supported attachment types if OpenID Connect for Identity Assurance 1.0
support is enabled. Empty if attachments are not supported. Corresponds to the
attachments_supported
OpenID provider metadata
parameter. Since v12.6.
Attachment types:
- embedded
- external
Example:
op.assurance.supportedAttachments=embedded,external
op.assurance.supportedDigestAlgs
The supported digest algorithms for external
attachments if OpenID Connect for
Identity Assurance 1.0 support is enabled. Corresponds to the
digest_algorithms_supported
OpenID provider
metadata parameter. If external attachments are
supported must at least include sha-256
. Since v12.6.
Example:
op.assurance.supportedDigestAlgs=sha-256
16. Mutual TLS
Settings for client authentication using mutual TLS.
op.tls.blockClientX509Certs
If true
submitted client X.509 certificates after passing the TLS layer will
not be considered at the token endpoint for the purposes of OAuth 2.0 client
authentication (tls_client_auth
and self_signed_tls_client_auth
) and access
token binding (cnf.x5t#S256
). This can be used to prevent binding of issued
access tokens to received client X.509 certificates when such binding is not
desired.
Blocking is disabled by default.
op.tls.blockClientX509Certs=false
op.tls.clientX509CertHeader
The name of the HTTP header to receive validated client X.509 certificates from
a TLS termination proxy. Intended to facilitate PKI mutual-TLS client
authentication (tls_client_auth
), self-signed mutual-TLS client
authentication (self_signed_tls_client_auth
) and issue of client certificate
bound access tokens.
The header name must be kept confidential between the TLS termination proxy and the Connect2id server and must include at least 32 random alphanumeric characters to make brute force guessing impractical.
The header value must be a PEM-encoded representation of the client X.509 certificate, with with optional additional URL-encoding of the PEM string.
If not specified or commented out use of a TLS termination proxy for mutual-TLS client authentication is disabled.
op.tls.clientX509CertHeader=X-Client-X509-Cert-alaeLuL8geiqu3OhOg1Mafa4Ecu9ahsh