OpenID Connect (OIDC) is a supported Single Sign-On (SSO) method in Absorb LMS that allows Users to authenticate using an external Identity Provider (IdP). This article explains how OIDC works in Absorb LMS, configuration options, and enhanced capabilities such as dynamic key retrieval and User Provisioning.

If you are looking for information about SAML 2.0, please review: Incoming SAML 2.0.

For more information about configuring OpenID Connect specific to Auth0, review OpenID Connect (OIDC) with Auth0.

Using OpenID Connect with Absorb LMS

OpenID Connect configurations in Absorb LMS support multiple JWT signature types and deployment models. Depending on your configuration, you can enable authentication only, dynamic key management, and optional User Provisioning. 

This article describes recommended setups, required claims, and known limitations.

Before You Configure OIDC

Before proceeding, review the following important requirements and considerations for OIDC in Absorb LMS.

• Absorb LMS supports the Authorization Code authentication flow for OIDC. Other flows (for example, implicit) are not supported.
• OIDC implementations vary by provider. Absorb LMS may not be compatible with every IdP’s OIDC implementation, so compatibility should be validated before production rollout.
• In our experience, OIDC implementations typically require more client-side development and configuration effort than SAML 2.0.

Supported Signature Types

Absorb LMS supports the following JWT signature types:

• HS256 (SHA-256): Shared secret (static key).
• RS256 (RSA-256): Public/private key pair (static upload or dynamic retrieval).

Additional configuration fields become available when RS256 is selected.

Configuration Scenarios

OpenID Connect can be configured in multiple ways depending on your JWT signature type, key management requirements, and whether you need to create Users automatically during authentication. Choose the scenario that matches your IDP configuration and your operational needs.

Scenario 1: HS256 (Authentication Only)

This scenario uses SHA-256 (HS256) as the JWT signature type. Authentication is performed using a shared secret, and advanced capabilities such as dynamic key retrieval and User Provisioning are not available.

How HS256 (Authentication Only) It Works

In an HS256 configuration, Absorb validates tokens using a static shared secret and does not attempt to create Users during sign-in.

• Absorb LMS authenticates Users using OpenID Connect with HS256-signed JWTs.
• Token validation is performed using a static shared secret rather than public/private key pairs.
• Signing keys are not retrieved dynamically from the IDP.
• Absorb validates the incoming token but does not attempt to create users during authentication.

HS256 (Authentication Only) Characteristics

This configuration supports authentication only and requires users to be pre-created in Absorb LMS.

• JWT signature type: SHA-256 (HS256)
• Dynamic keys: Not supported
• User provisioning: Not supported
• Authentication only: Yes
• User requirement: Users must already exist in Absorb LMS
• Key model: Shared secret (static)

HS256 (Authentication Only) User Experience

Existing Users in Absorb LMS can authenticate successfully using OpenID Connect. Users who do not already exist in Absorb LMS will not be created automatically and will be unable to complete authentication.

When to Use HS256 (Authentication Only)

HS256 is typically used to maintain existing configurations or when shared-secret signing is required.

• Maintaining an existing OpenID Connect configuration that uses HS256.
• Environments where shared-secret-based signing is required.
• Scenarios where User accounts are provisioned outside of the OpenID Connect authentication flow.

Important Notes About HS256 (Authentication Only)

Organizations that want automated key management or User Provisioning should use RS256 with dynamic keys enabled.

Scenario 2: RS256 Without Dynamic Keys (Authentication Only)

This scenario uses RSA-256 (RS256) as the JWT signature type, but does not enable dynamic key retrieval. Authentication uses asymmetric cryptography, but key management remains manual.

How RS256 Without Dynamic Keys (Authentication Only) Works

In this configuration, Absorb validates incoming tokens using a public signing key or certificate that you upload manually. Absorb does not retrieve signing keys dynamically and does not create Users during authentication.

• Absorb LMS authenticates Users using OpenID Connect with RS256-signed JWTs.
• Token validation is performed using a public signing key or certificate provided by the IDP.
• Signing keys are configured statically and are not retrieved dynamically.
• Absorb validates the incoming token but does not attempt to create Users during authentication.

RS256 Without Dynamic Keys (Authentication Only) Characteristics

This configuration supports authentication only and requires Users to be pre-created in Absorb LMS.

• JWT signature type: RSA-256 (RS256)
• Dynamic keys: Disabled
• User provisioning: Not supported
• Authentication only: Yes
• User requirement: Users must already exist in Absorb LMS
• Key model: Public/private key pair (static configuration)

RS256 Without Dynamic Keys (Authentication Only) User Experience

Existing users in Absorb LMS can authenticate successfully using OpenID Connect. Users who do not already exist in Absorb LMS will not be created automatically and will be unable to complete authentication.

When to Use RS256 Without Dynamic Keys (Authentication Only)

RS256 without dynamic keys may be used when RSA-based signing is required but dynamic key retrieval is not enabled or permitted.

• Environments that require RSA-based token signing.
• Scenarios where dynamic key retrieval is not enabled or not permitted.
• Organizations that manage User creation through separate provisioning processes.

Important Notes About RS256 Without Dynamic Keys (Authentication Only)

While RS256 is more secure than shared-secret approaches, this configuration still requires manual key management. To enable automated key management and User Provisioning, dynamic keys must be enabled.

Scenario 3: RS256 With Dynamic Keys (Recommended)

This scenario uses RSA-256 (RS256) with Use Dynamic Keys enabled. Absorb retrieves signing keys from the IdP’s discovery endpoint, supports key rotation without manual updates, and provides optional User Provisioning during authentication.

How RS256 With Dynamic Keys Works

In this configuration, Absorb validates incoming tokens using dynamically retrieved signing keys. If Allow User Provisioning is enabled, Absorb can create a User when one does not already exist.

• Absorb LMS authenticates users using OpenID Connect with RS256-signed JWTs.
• Signing keys are retrieved dynamically from the IDP, removing the need for manual key updates.
• During authentication, Absorb validates the incoming token using the dynamically retrieved keys.
• If Allow User Provisioning is enabled, Absorb attempts to create a User when one does not already exist.

RS256 With Dynamic Keys Characteristics

This configuration supports dynamic key retrieval and optional User Provisioning.

• JWT signature type: RSA-256 (RS256)
• Dynamic keys: Enabled
• User provisioning: Available (toggle-controlled)
• Authentication: Yes
• User creation: Supported when provisioning is enabled
• Key model: Public/private key pair (dynamic retrieval)

RS256 With Dynamic Keys User Experience

Existing Users in Absorb LMS authenticate normally. New Users can be created automatically during authentication (when provisioning is enabled), eliminating the need for pre-created accounts. Authentication remains seamless even when signing keys rotate at the IDP.

When to Use RS256 With Dynamic Keys

This scenario is recommended for new implementations and environments where on-boarding needs to be automated.

• New OpenID Connect implementations.
• Environments with external Users or delayed on-boarding.
• Organizations that want to minimize manual key management and reduce administrative overhead.

Important Notes About RS256 With Dynamic Keys

RS256 is required to enable dynamic keys, and dynamic keys are required to enable User Provisioning.

• When User Provisioning is enabled, additional scopes are required in your IdP: openid, email, profile, phone, and address.
• Admin roles cannot be assigned through OpenID Connect.
• Manager Experience is not supported with OpenID Connect authentication.

Enhanced Capabilities

When RS256 and Use Dynamic Keys are enabled, Absorb can automatically retrieve signing keys and optionally create Users during authentication.

Dynamic Key Retrieval

Dynamic keys are retrieved from the IdP’s Discovery URL (the OIDC metadata endpoint). Use this option when your IdP supports discovery and key rotation to avoid manual key updates.

• Requires RS256.
• Supports key rotation without manual certificate updates.
• Required to enable User Provisioning.

User Provisioning

When Allow User Provisioning is enabled, Absorb attempts to create a User record during authentication if a matching User does not already exist.

Absorb uses the email claim as the sole unique identifier (UID) for OIDC matching and provisioning. Ensure email values are present, unique in Absorb LMS, and consistent between your IdP and Absorb to avoid duplicate accounts or No matching Absorb user found errors.

Required Claims for Provisioning

If provisioning is enabled, the following OIDC standard claims must be present:

• given_name (required)
• family_name (required)
• email (required)

Absorb-specific attributes should use the urn:absorb: prefix (for example: urn:absorb:department-id, urn:absorb:external-department-id, urn:absorb:job-title, urn:absorb:username, urn:absorb:user-external-id).

Limitations

The following limitations apply to OpenID Connect in Absorb LMS.

Accessing OIDC Settings in Absorb

To configure OpenID Connect, you must have System Admin permissions.

1. Log in to Absorb as a System Admin.
2. Access the Admin Experience.
3. Navigate to Client Settings and open the SSO card.
   
    
4. Click Add SSO Configuration to create a new SSO configuration.
   
    
5. Select OpenID Connect as the method.
   
    

Core Fields to Provide

When adding an OIDC configuration, populate the following fields.

• OpenID Connect Authentication Flow Mode: Authorization Code.
• OpenID Connect Authentication Protocol Method: Client Secret Basic or Client Secret Post.
• JWT Signature Type Used for Authentication: HS256 or RS256.
• Client Identifier from the Authorization Server: Client ID.
• Client Secret from the Authorization Server: Client secret.
• Issuer URL: The issuer used by your IdP.
• Authorization Endpoint URL: Endpoint used to initiate authentication.
• Token Endpoint URL: Endpoint used to exchange authorization codes for tokens.
• Automatically Redirect: Automatically redirects unauthenticated users to the IdP login page.
• Enforce Admin Side SSO: Enforces SSO redirection on the Admin login page.
• Assigned Routes: LMS routes that trigger OIDC authentication.
• Pass Client ID in Scopes: When enabled, includes the configured Client ID in the scopes sent to the identity provider.
  • Enable this setting when using Azure Active Directory B2C (Azure AD B2C), as it requires the Client ID to be included in the request.
  • For all other identity providers, leave this setting disabled.

RS256-Only Fields

If you select RS256, additional configuration options are available depending on whether you enable dynamic keys.

• Use Dynamic Keys: Retrieves signing keys dynamically from the IdP.
• Discovery URL: The IdP URL used to discover OIDC metadata (including dynamic signing keys). This field is used when Use Dynamic Keys is enabled.
• Allow User Provisioning: Creates Users automatically during authentication if they do not already exist.

If Use Dynamic Keys is disabled, you must provide a public signing key or certificate for token validation.

• Public Signing Key or Certificate from the Authorization Server: Required only when dynamic keys are not enabled.
• The certificate entered in this field must be in x509 format.

ID Property Requirement

Absorb matches and provisions users using the incoming email claim. For OIDC, Email Address is the only valid ID Property.

FAQ

The following questions address common configuration and capability considerations for OpenID Connect in Absorb LMS.

Which OpenID Connect Configuration Should I Use?

For new implementations, RS256 with Use Dynamic Keys enabled is recommended. This configuration supports dynamic key management and optional User Provisioning.

Does OpenID Connect Support User Provisioning?

Yes. User Provisioning is supported when RS256 is selected, Use Dynamic Keys is enabled, and Allow User Provisioning is turned on.

What Identifier Is Used to Uniquely Identify Users During Provisioning?

When provisioning Users through OpenID Connect, the Email Address is the only unique identifier (UID) used by Absorb LMS. User Provisioning and User matching are performed based on the email address.

Can I Continue Using an Existing HS256 or RS256 Static Configuration?

Yes. Existing configurations will continue to work, but they do not support dynamic keys or User Provisioning.

Can OpenID Connect Be Used for the Manager Experience?

No. The Manager Experience is not supported when using OpenID Connect.

Can Administrators Be Provisioned or Assigned Through OpenID Connect?

No. Administrative Roles cannot be assigned or managed through OpenID Connect and must be handled separately.

Can Supervisors Be Mapped When Using OpenID Connect?

Yes. Supervisor mapping is supported, but the Supervisor must already be assigned as an Admin in Absorb LMS. OpenID Connect does not support assigning Admin roles.

Is OpenID Connect Compatible with All Identity Providers?

No. While many IDP support OpenID Connect, implementations vary. Compatibility should be validated with the chosen IDP before production rollout.

User Provisioning Claims

When Allow User Provisioning is enabled for OpenID Connect, Absorb LMS evaluates claims from the IDP to create and populate User records. These claims fall into two categories: OIDC standard claims and Absorb-specific claims.

OIDC Standard Claims

These claims are populated from the IDP user profile and typically cannot be set manually.

• given_name (required)
• family_name (required)
• middle_name
• email (required)
• phone_number

Absorb-Specific Claims

All Absorb-specific claims use the prefix urn:absorb: to ensure they are uniquely identified as Absorb LMS claims.

The following claims can be provided to populate user profile fields in Absorb.

• urn:absorb:department-id
  • Required if urn:absorb:external-department-id is not provided. Must match an LMS department ID.
• urn:absorb:external-department-id
  • Required if urn:absorb:department-id is not provided. Can only match one Department in the LMS.
• urn:absorb:address
• urn:absorb:address2
• urn:absorb:city
• urn:absorb:country-code
  • Must be an ISO 3166-1 Alpha-2 or Alpha-3 code (for example, Canada can be CA or CAN).
• urn:absorb:postal-code
• urn:absorb:province-code
  • Must be an ISO 3166-2 subdivision code. For example, Alberta, Canada is listed as CA-AB in ISO 3166-2, but Absorb expects AB.
• urn:absorb:date-hired
• urn:absorb:employee-number
• urn:absorb:gender
  • Limited to male, female, or none. If not provided, none will be set.
• urn:absorb:job-title
• urn:absorb:language-code
  • Must be a 2-letter ISO 639-1 code and must be limited to languages configured in Portal Settings > Defaults > Available Languages.
• urn:absorb:location
• urn:absorb:supervisor-identifier
  • Supervisor’s Email Address. The Supervisor must already exist in Absorb LMS and must be an Admin (includes Department Admin and Group Admin).
• urn:absorb:user-external-id
  • Must not already exist in Absorb LMS.
• urn:absorb:username
  • If not available, Absorb uses the Email Address as the Username. Must not already exist in Absorb LMS.

Custom Fields

Custom field claims map directly to corresponding custom fields configured in Absorb LMS.

Boolean Fields

Values must be true, false, or null (or an empty string).

• urn:absorb:custom-field-bool1
• urn:absorb:custom-field-bool2
• urn:absorb:custom-field-bool3
• urn:absorb:custom-field-bool4
• urn:absorb:custom-field-bool5

Datetime Fields

Provide datetime values in the format expected by your IDP and token configuration.

• urn:absorb:custom-field-datetime1
• urn:absorb:custom-field-datetime2
• urn:absorb:custom-field-datetime3
• urn:absorb:custom-field-datetime4
• urn:absorb:custom-field-datetime5

Decimal Fields

Provide numeric values that can be parsed as decimals.

• urn:absorb:custom-field-decimal1
• urn:absorb:custom-field-decimal2
• urn:absorb:custom-field-decimal3
• urn:absorb:custom-field-decimal4
• urn:absorb:custom-field-decimal5

String Fields

Use the following claims to map into Absorb custom string fields.

• urn:absorb:custom-field-string1 through urn:absorb:custom-field-string30

Important Notes

Review the following requirements to avoid provisioning failures.

• Required claims must be present for User Provisioning to succeed.
• Claims that must be unique (such as Username or External ID) must not already exist in Absorb LMS.
• OpenID Connect does not support assigning Admin roles, so Supervisors must already have Admin access before Supervisor mapping can be applied.

Troubleshooting

If you capture the ID token or JWT, decode it at https://jwt.io to verify claims and signature metadata.

Common Errors

The following errors have known causes that can be addressed.

500 error: “An unexpected error occurred”

This can occur for a variety of issues. Use the checks below to troubleshoot.

• Confirm that the Issuer URL entered in Absorb exactly matches the issuer in your IdP’s /.well-known/openid-configuration. This includes any trailing / at the end of the URL.
• If you are using a static key configuration, confirm the signature being used matches the value provided in the Public Signing Key or Certificate field.
• Confirm the JWT signature type selected in Absorb (HS256 or RS256) matches what is configured in your IdP.
• Choose a client secret that is 64 characters (512-bit) in length regardless of the JWT signature type chosen.

“The token response does not contain a valid subject or email claim.”

Confirm that the token payload includes a value labeled email (or emails) and that the value is populated.

“No matching Absorb user found”

Absorb looks at the value sent for email in the token payload and matches it to the Email Address ID Property in Absorb. This error indicates one of the following:

• User Provisioning is disabled, and there is no matching active User in Absorb LMS.
• User Provisioning is enabled, but required claims or scopes are missing and User creation did not succeed.

Additional Notes

For new implementations, RS256 with Use Dynamic Keys enabled is recommended. Existing HS256 and RS256 static configurations will continue to work, but they do not support dynamic keys or user provisioning. Validate compatibility with your chosen IdP before production rollout.