OAUTH2/OIDC properties setup

OIDC properties

Here's where you can complete all of the OAuth2/OIDC-specific settings for integration with your single-page or multi-page web application.

📘
Once you have completed all of these fields and saved your settings, you can integrate your customer interfaces using OIDC with the following options:

Redirection

Popup

Strivacity self-service

Client ID

The Client ID is automatically generated when you save the Application at the end of this process. This is the primary identifier used by your application to trust Strivacity when it performs any services on its behalf (such as authentication). This is public.

Client Secret

The Client Secret is automatically generated when you save the Application at the end of this process. This is a secret used by your application to trust Strivacity when it performs any services on its behalf (such as authentication). This should be kept private.

Token endpoint authentication method

This setting specifies how Strivacity expects clients to authenticate with the token endpoint during OAuth2/OIDC flows. The following options are available:

None: No client secret is required. This is typically used for public clients, such as mobile or single-page applications, that implement the PKCE (Proof Key for Code Exchange) flow.
BASIC: Authentication credentials (client ID and secret) are sent in the HTTP Authorization header using Basic Authentication.
POST: Authentication credentials are included in the HTTP POST request body as form parameters.
JWT: A JSON Web Token (JWT) signed with the client’s private key is sent in the request body for authentication. When this option is selected, one of the following additional configurations must be provided:
- JSON Web Key Set URL: A URL pointing to the JSON Web Key Set (JWKS), which contains the public keys used for verifying JWT signatures. The URL must not exceed 1,000 characters.
- JSON Web Key Set: The full JSON Web Key Set, provided directly as a string. The value must not exceed 8,000 characters.

Example JWKS:

{
  "keys": [
    {
      "kty": "RSA",
      "n": "<key data>",
      "e": "AQAB",
      "use": "sig",
      "kid": "a-key-id"
    }
  ]
}

📘
The Token endpoint authentication method setting corresponds to the OIDC token_endpoint_auth_method parameter. For most applications, the default option (BASIC) is sufficient. Change this setting only if your application requires a specific authentication method.

JWT signing method

Strivacity uses RS256 as the default algorithm for signing the JSON Web Tokens (JWTs). RS256 generates and uses an asymmetric signature.

Allowed callback URLs

Here, you can configure the allowed callback URLs for the OIDC transaction. This typically corresponds to the redirect_uri that an OIDC client passes to Strivacity when a user wants to authenticate.

Allowed logout URLs

Here is where you configure the allowed Logout URLs for the OIDC transaction. This typically corresponds to logout_uri that an OIDC client would pass to Strivacity when a user initiates a logout transaction.

Login URL

The Login URL is a URL related to your brand application that can

automatically initiate a login and redirect to the specific client authorization endpoint
pass the received acr_values and login_hint GET parameter to the login

🚧
Note
The Strivacity-hosted login page is not an entry point to the customer authentication flow.

Dialects

Here is where you can specify the claim dialect that is used by this Application. By default, the 'OpenID Connect' default claim dialect is used.

Enable interactive login and registration

Switch off interactive login and registration when you want to use an application exclusively for machine-to-machine communication, such as with APIs. This is essential, as APIs will not work unless this option is set to disabled. By doing so, customers won't be able to log in to your application.

Enable self-service API access

Allows access tokens issued by this client to be used for calling self-service APIs within the same application. Enable this option to permit API-driven self-service functionality for customers.

Enable refresh tokens

📘
Refresh tokens are long-lived credentials that can request new access tokens when the current one expires, ensuring a seamless and uninterrupted customer experience.

This is a customer convenience setting where you can enable or disable the use of refresh tokens, which means that any OIDC tokens can automatically refresh without requiring the customer to log back in.

Refresh token lifespan

The refresh token lifespan determines the duration for which a refresh token remains valid if refresh tokens are enabled, allowing customers to obtain new access tokens without re-authenticating until the lifespan expires.

The lifetime of refresh tokens is set to 30 days by default.

ID token lifespan

📘
An ID token is a security token used in the OIDC protocol that contains information about the customer's identity, such as their name, email, and authentication details. It is issued by the authentication server after a successful login and is used by the client application to verify the customer's identity.

The ID token lifespan specifies how long an ID token is valid, defining the time period during which the token can be used to authenticate and retrieve customer identity information.

Access token lifespan

📘
An access token is a credential issued by an authorization server that grants a client application permission to access specific resources or APIs on behalf of a customer. It is typically short-lived and is used to authenticate and authorize requests to protected resources without needing the customer to log in again.

The access token lifespan determines the duration for which an access token remains valid, allowing access to protected resources within that time frame.

Access token format

You can choose the format of access tokens based on your security and interoperability needs. The available options are:

JWT (JSON Web Token): This format provides a self-contained token with a structured payload, allowing you to embed claims and metadata directly within the token. JWTs can be independently verified and decoded, making them suitable for scenarios requiring stateless token validation and detailed token information.
Opaque Token:This format uses a random, non-readable string that does not convey any information about the customer or the token itself. All relevant data is stored on the server, and the token's validity is checked by querying the authorization server or token introspection endpoint. Opaque tokens are useful when you want to keep token content hidden from the client and manage all token-related data server-side.