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:

Any configuration file property 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 identifying URL of the OpenID provider / OAuth 2.0 authorisation server. The ID and access tokens will have their issuer (iss) claim 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.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.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 optionally 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==

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.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

3. 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
  • ЕS384
  • ЕS512
  • HS256
  • HS384
  • HS512
  • 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,ES384,ES512,HS256,HS384,HS512

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 (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,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
op.idToken.jweEncs=A128CBC-HS256,A192CBC-HS384,A256CBC-HS512,A128GCM,A192GCM,A256GCM

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.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

4. 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

5.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=900

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

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

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
  • 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,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 (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,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
op.authz.requestJWEEncs=A128CBC-HS256,A192CBC-HS384,A256CBC-HS512,A128GCM,A192GCM,A256GCM

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.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 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 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 or login_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 and consent_required errors by itself.
op.authz.alwaysPromptMode=PROMPT_NONE

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 OpenID prompt=none authentication 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_uris 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_uris 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.requireRequestJWTExpiration

Specifies if received request JWTs must include an expiration (exp) claim. The default value is false.

op.authz.requireRequestJWTExpiration=false

op.authz.requireAllParamsInRequestJWT

Specifies if received request JWTs must include all authorisation request parameters which are found as query parameters. If enabled authorisation requests with unsecured query parameters will be rejected with an invalid_request error. The default value is false.

op.authz.requireAllParamsInRequestJWT=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

6. 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 which don't specify one explicitly during registration.

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
  • 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.

To enable all supported client authentication methods:

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, HS512

  • For private_key_jwt authentication : RS256, RS384, RS512, PS256, PS384, PS512, ES256, 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

7. Token Introspection Endpoint

The op.token.introspection.* properties configure the token introspection endpoint.

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 allows 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

8. 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
  • ES384
  • ES512
  • HS256
  • HS384
  • HS512

Tp enable all supported JWS algorithms:

op.userinfo.jwsAlgs=RS256,RS384,RS512,PS256,PS384,PS512,ES256,ES384,ES512,HS256,HS384,HS512

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 (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,ECDH-ES,ECDH-ES+A128KW,ECDH-ES+A192KW,ECDH-ES+A256KW,dir,A128KW,A192KW,A256KW,A128GCMKW,A192GCMKWA256GCMKW

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
op.userinfo.jweEncs=A128CBC-HS256,A192CBC-HS384,A256CBC-HS512,A128GCM,A192GCM,A256GCM

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

9. 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

10. 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

11. Back-channel Logout

The op.logout.backChannel.* properties configure the dispatch of back-channel logout tokens.

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

12. 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.

Since v10.0.

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.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 intermediate entities or trust anchors 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.policyURI

URL of the federation entity policy. The URL can be also be 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 be 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

13. Identity assurance

Settings for OpenID Connect for Identity Assurance 1.0.

Since v8.0.

op.assurance.supportsVerifiedClaims

Enables / disables advertisement of OpenID Connect for Identity Assurance 1.0 support in OpenID provider metadata and enables Connect2id server processing of verified claims. 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.

op.assurance.supportedTrustFrameworks=nist_800_63A_ial_2,nist_800_63A_ial_3

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.

op.assurance.supportedIdentityEvidenceTypes=id_document,utility_bill,qes

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.

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.

op.assurance.supportedIdentityVerificationMethods=pipp,sripp,eid

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

14. Mutual TLS

Settings for client authentication using mutual TLS with client X.509 certificates.

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 self-signed (public key) TLS client authentication (self_signed_tls_client_auth).

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. The additional URL-encoding of the PEM string is accepted since v8.1.

If not specified or commented out use of a TLS termination proxy for self-signed TLS client authentication is disabled.

op.tls.clientX509CertHeader=X-Client-X509-Cert-alaeLuL8geiqu3OhOg1Mafa4Ecu9ahsh