LMS SSO Integration: The Definitive SAML 2.0 vs OAuth 2.0 / OIDC Guide for Enterprise Admins and Developers 2026

The practical problem this guide solves is specific: your LMS is rejecting SSO assertions, your IdP metadata exchange failed, or you are choosing between SAML 2.0 and OIDC for a new LMS deployment and the guidance you have found conflates authorization with authentication. Most published content on SSO protocol selection is written for generic SaaS scenarios. None of it covers the LMS-specific gotchas, attribute mapping to training roles, SCIM provisioning alongside SSO, Single Logout (SLO) implementation, or multi-tenant LMS SSO architecture, that are responsible for the majority of LMS SSO support tickets.

This guide covers SAML 2.0 (OASIS standard, current specification published March 2005, actively maintained) and OpenID Connect 1.0 (OpenID Foundation, published February 2014, built on OAuth 2.0 / RFC 6749). OAuth 2.0 itself is an authorization framework, not an authentication protocol, a distinction that matters operationally when you are debugging a broken LMS login flow. Where the guide references ‘OAuth 2.0’ it refers specifically to the delegated API authorization use case; OIDC is the correct term for identity-layer SSO built on OAuth 2.0.

Who’s this guide for: LMS administrators responsible for IdP configuration, developers building custom LMS integrations, and IT directors evaluating SSO architecture for enterprise LMS deployments. SCORM and xAPI content delivery is not affected by SSO protocol choice, but user provisioning, role assignment, and session management are.

SAML 2.0 vs OIDC: Protocol Architecture for LMS Deployments

SAML 2.0: How the Assertion Flow Works

The SAML 2.0 (OASIS standard urn:oasis:names:tc:SAML:2.0) uses XML-encoded assertions, signed with X.509 certificates, transmitted via HTTP Redirect (GET) or HTTP POST bindings. In a standard SP-initiated flow, the LMS (Service Provider / SP) redirects the browser to the IdP’s SingleSignOnService endpoint. The IdP authenticates the user and posts a signed samlp:Response containing one or more saml:Assertion elements back to the LMS’s Assertion Consumer Service (ACS) URL.

The assertion carries identity claims and role attributes in saml:AttributeStatement blocks, this is where LMS-specific attribute mapping lives. A misconfigured attribute name (e.g., sending department instead of http://schemas.xmlsoap.org/ws/2005/05/identity/claims/department) is the most common cause of silent role-mapping failures in enterprise LMS deployments.

Annotated SAML 2.0 Assertion, LMS Role Attribute Example:

SAML 2.0, SP-Initiated Flow, LMS Attribute Assertion

<samlp:Response xmlns:samlp=”urn:oasis:names:tc:SAML:2.0:protocol”

Destination=”https://lms.example.com/saml/acs”

InResponseTo=”_req-abc123″>

<saml:Assertion xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion”

IssueInstant=”2026-03-27T08:30:00Z”>

<saml:Issuer>https://idp.example.com/saml</saml:Issuer>

<saml:Subject>

<saml:NameID Format=”urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress”>

j.smith@example.com

</saml:NameID>

</saml:Subject>

<!– NotBefore / NotOnOrAfter: clock skew tolerance <= 5 minutes –>

<saml:Conditions NotBefore=”2026-03-27T08:28:00Z”

NotOnOrAfter=”2026-03-27T08:35:00Z”>

<saml:AudienceRestriction>

<saml:Audience>https://lms.example.com</saml:Audience>

</saml:AudienceRestriction>

</saml:Conditions>

<saml:AttributeStatement>

<!– Map to LMS user profile fields –>

<saml:Attribute Name=”email”>

<saml:AttributeValue>j.smith@example.com</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute Name=”role”>

<!– LMS role name must match exactly, case-sensitive –>

<saml:AttributeValue>compliance_learner</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute Name=”department”>

<saml:AttributeValue>FO_TRADER_EQ</saml:AttributeValue>

</saml:Attribute>

</saml:AttributeStatement>

</saml:Assertion>

</samlp:Response>

OIDC / OAuth 2.0: How the Token Flow Works in LMS Context

OpenID Connect 1.0 uses the Authorization Code Flow (recommended for server-side LMS applications) or Authorization Code + PKCE for SPAs and mobile LMS clients. The LMS redirects the user to the IdP’s /authorize endpoint with response_type=code and scope=openid profile email. After authentication, the IdP returns a short-lived authorization code. The LMS backend exchanges this code at the /token endpoint for an ID Token (JWT) and an Access Token.

The ID Token carries identity claims (sub, email, name) plus any custom claims your IdP is configured to include. LMS role assignment in OIDC deployments typically uses custom claims in the ID Token, the equivalent of the SAML AttributeStatement. Unlike SAML, OIDC tokens expire and must be refreshed, adding a session management consideration that SAML deployments handle via the SP-maintained session rather than token lifetime.

OIDC ID Token Payload, LMS Custom Claims Example:

OIDC ID Token, JWT Payload with LMS Custom Claims

{

“iss”: “https://idp.example.com“,

“sub”: “user-id-48291”,

“aud”: “lms-client-id-abc123”, // Must match LMS client_id exactly

“exp”: 1743069000, // Token expiry, 1 hour default

“iat”: 1743065400,

“nonce”: “n-0S6_WzA2Mj”, // PKCE: required for replay protection

// Standard OIDC claims

“email”: “j.smith@example.com“,

“email_verified”: true,

“name”: “Jane Smith”,

// Custom enterprise claims, configure in IdP token policy

“custom:lms_role”: “compliance_learner”,

“custom:department”: “FO_TRADER_EQ”,

“custom:manager_id”: “mgr-00412”,

“groups”: [“equities”, “compliance_mandatory”]

}

OAuth 2.0 Scope: Authorization Only, Not Authentication

A critical misconception seen consistently in LMS SSO implementations: OAuth 2.0 alone cannot authenticate a user. OAuth 2.0 (RFC 6749) grants delegated access to resources, it answers the question ‘what can this app access?’ not ‘who is this user?’. Using a bare OAuth 2.0 Access Token as a login credential without the OIDC layer leaves the LMS with no verified user identity. The correct architecture is OIDC for authentication (ID Token) plus OAuth 2.0 for API access (Access Token). Every major IdP, Microsoft Entra ID, Okta, Auth0, Ping Identity, exposes OIDC endpoints; there is no reason to implement bare OAuth 2.0 for LMS SSO in 2026.

LMS SSO Compatibility Matrix: Protocol and IdP Support

Protocol Capability Comparison

✓ = Fully supported by spec | ◑ = Partial / limited support | ✗ = Not supported / not the correct protocol for this use case.

Enterprise LMS Platform SSO Protocol Support (2026)

SCIM Prov. = SCIM 2.0 user lifecycle provisioning. SLO = Single Logout. Moodle plugin-based support requires SimpleSAMLphp or the OAuth2 OIDC plugin. Verify current version support directly with the LMS vendor before implementation.

LMS Attribute Mapping: IdP Attribute Names to LMS Fields

The following table covers the most common IdP attribute name formats that LMS platforms require. Mismatches between the name format sent by the IdP and what the LMS expects are responsible for the majority of ‘user authenticated but wrong role / blank profile’ support tickets.

Entra ID attribute URIs are case-sensitive. OIDC custom claims must be explicitly added to the IdP token policy, they are not included by default. Verify attribute names in IdP’s SAML tracer or OIDC token inspector before configuring LMS mapping.

Implementation Steps for Enterprise LMS SSO Configuration

Phase 1, Protocol and IdP Selection

Choose SAML 2.0 if: your LMS will integrate with a legacy on-prem identity system (ADFS, Shibboleth, IBM Security Verify); you operate in a regulated industry where SAML assertion logging is required for compliance audits; or your LMS vendor’s OIDC support is listed as beta or plugin-only.

Choose OIDC if: you are deploying a mobile LMS app or SPA, your IdP is a modern cloud-native platform (Entra ID, Okta, Auth0), and your team is more familiar with REST/JSON debugging than XML/XPath. OIDC certificate management via JWKS (JSON Web Key Set) is substantially simpler than X.509 SAML certificate rotation.

Phase 2, SAML 2.0 LMS Configuration Steps

1. Export SP metadata from LMS. Most enterprise LMS platforms expose a metadata URL at /saml/metadata or /auth/saml/metadata.xml. This XML document contains your EntityID, ACS URL, and public signing certificate. Do not manually construct it.
2. Register the LMS as a SAML SP in your IdP. Import the SP metadata XML. Alternatively, enter EntityID and ACS URL manually, but metadata import avoids transcription errors in certificate encoding.
3. Configure attribute mappings in the IdP. Use the Attribute Mapping table (above) to identify which attribute names your IdP sends. Configure the IdP’s claim/attribute policy to emit email, first name, last name, department, and any LMS-specific role attributes. Verify attribute names match exactly what the LMS expects, including URI prefix format.
4. Export IdP metadata and import into LMS. The IdP metadata XML contains the SingleSignOnService URL, SingleLogoutService URL, and X.509 signing certificate. Import it into the LMS SAML configuration panel. Do not hardcode certificate strings, import from metadata.
5. Configure SLO endpoints. Add the IdP’s SingleLogoutService URL to the LMS SAML config. Ensure the LMS’s own SingleLogoutService URL is listed in the IdP SP registration.
6. Test with SAML tracer before production. Use the SAML-tracer browser extension (Firefox/Chrome) to capture the assertion. Verify NotBefore / NotOnOrAfter conditions, audience restriction, and attribute values. This single step prevents 80% of go-live incidents.
7. Enable JIT provisioning if required. Just-in-Time provisioning creates an LMS user record on first successful SAML login if no matching account exists (matched on email / NameID). Confirm with the LMS vendor whether JIT creates the account with the asserted role or a default role.

Phase 3, OIDC / OAuth 2.0 LMS Configuration Steps

1. Register the LMS as an OIDC client (Relying Party). In your IdP, create a new OIDC application. Select Authorization Code flow (not Implicit). Record the client_id and client_secret. Set the Redirect URI to the LMS’s OIDC callback URL, this must match exactly, including trailing slash.
2. Configure scopes and custom claims. Request openid profile email as minimum scopes. For LMS role/department mapping, add custom claims to the IdP’s token policy. Configure the LMS to read these claims from the ID Token.
3. Enable PKCE for mobile / SPA LMS clients. PKCE (Proof Key for Code Exchange, RFC 7636) is mandatory for public clients and recommended for all OIDC flows in 2026. Confirm your LMS client-side code generates a code_verifier and code_challenge per the spec.
4. Configure the discovery endpoint. Most OIDC IdPs expose /.well-known/openid-configuration. Point the LMS at this URL rather than hardcoding individual endpoint URLs, it handles IdP endpoint changes automatically.
5. Configure token lifetimes and refresh. ID Tokens default to 1 hour on most IdPs. Align the LMS session timeout to the token lifetime to avoid mid-session re-authentication prompts. Configure Refresh Token rotation if your LMS supports background token refresh.
6. Configure end_session_endpoint for SLO. Pass the id_token_hint (the user’s current ID Token) and post_logout_redirect_uri to the IdP’s logout endpoint. Without id_token_hint, most IdPs present a logout confirmation page rather than completing SLO silently.

SCIM 2.0: Provisioning Alongside SSO

SSO handles authentication; SCIM 2.0 (RFC 7642–7644) handles user lifecycle, account creation, attribute updates, and deprovisioning when employees leave. In a regulated environment, SCIM is not optional: manual deprovisioning processes lag HRIS termination events by days, creating orphaned LMS accounts that represent a compliance risk. Configure SCIM alongside SSO, not as a future follow-on item.

SCIM endpoint in LMS platforms is typically at /scim/v2 or similar. Authentication is bearer token (not SSO credentials). Test user PATCH and DELETE operations in staging before production, SCIM DELETE should suspend the LMS account, not hard-delete training history.

Common LMS SSO Issues and Fixes

Issue 1: SAML Assertion Rejected, ‘NotOnOrAfter’ Condition Failure

Symptom: LMS returns ‘AuthnResponse is no longer valid’ or ‘Assertion has expired’ immediately after the IdP redirects. The assertion is technically valid but the LMS rejects it.

Root cause: Clock skew between the IdP server and the LMS application server. SAML 2.0 NotOnOrAfter is evaluated against the receiving server’s clock. A skew of more than 5 minutes (the de facto tolerance) causes immediate rejection. This is one of the most common SAML issues in cloud LMS deployments where the LMS is hosted on auto-scaled instances without enforced NTP synchronisation.

Fix: Enforce NTP synchronisation on all LMS application servers. Configure NTP to use a reliable stratum-2 source (e.g., pool.ntp.org). In the LMS SAML configuration, set the allowed clock skew tolerance if configurable (typically 120–300 seconds). Verify server time with timedatectl (Linux) or w32tm /query /status (Windows). Reference: SAML 2.0 Core Specification §2.5.1.

Issue 2: Authenticated but Wrong LMS Role, Silent Attribute Mapping Failure

Symptom: The learner can log in via SSO but lands in a default or guest role rather than their assigned training group. No error is displayed.

Root cause: The attribute name sent in the SAML AttributeStatement (or OIDC custom claim key) does not match the attribute name the LMS is configured to read. The LMS silently assigns the default role. Common mismatch: IdP sends groups; LMS expects http://schemas.microsoft.com/ws/2008/06/identity/claims/groups.

Fix: Use SAML-tracer (browser extension) to capture the raw samlp:Response and identify the exact Name attribute of each saml:Attribute element. Compare against the LMS attribute mapping configuration character-for-character. For OIDC, use the IdP’s token inspector (Okta: Token Preview; Entra ID: claims-testing tool in App Registration) to verify the exact claim key and value in the ID Token before configuring LMS claim mapping.

Issue 3: OIDC Redirect URI Mismatch, ‘redirect_uri_mismatch’ Error

Symptom: After IdP authentication, the browser returns an error page: error=redirect_uri_mismatch or The redirect URI provided does not match a pre-registered redirect URI.

Root cause: The Redirect URI registered in the IdP does not match exactly the URI the LMS is sending in the /authorize request. Common mismatch sources: HTTP vs HTTPS; trailing slash present in one but not the other; URL-encoded characters in the LMS’s request vs literal characters in the registration; www subdomain mismatch after domain migration.

Fix: In the IdP application registration, add the exact Redirect URI from the LMS’s OIDC debug log. Many IdPs allow multiple registered redirect URIs, register both with and without trailing slash to cover both. After a domain change or Enhanced Domain enforcement (relevant for Salesforce deployments as of late 2025), update all registered redirect URIs before disabling legacy domains.

Issue 4: SLO Not Executing, User Remains Authenticated After LMS Logout

Symptom: Clicking ‘Logout’ in the LMS clears the LMS session but the user can immediately re-access the LMS (or other SSO-connected apps) without re-authenticating.

Root cause: SLO is not configured. The LMS session is cleared but the IdP session (SSO cookie) remains active. This is the default state if SLO endpoints were not configured at implementation, extremely common in implementations that treated SLO as a post-go-live task.

Fix (SAML): Verify the LMS’s SingleLogoutService URL is registered in the IdP SP configuration. Verify the IdP’s SingleLogoutService URL is in the LMS SAML settings. Initiate a SAML logout from the LMS and capture the LogoutRequest in SAML-tracer, confirm the IdP is returning a LogoutResponse.

Fix (OIDC): Confirm the LMS is calling the IdP’s end_session_endpoint from the discovery document. Include the id_token_hint parameter, without it, Okta and Entra ID will show an interactive logout confirmation page rather than silent SLO. Include post_logout_redirect_uri to return the user to the LMS login page after IdP session clearance.

Issue 5: SCIM Deprovisioning Deletes Training Records

Symptom: When an SCIM DELETE event is received (employee termination), the LMS hard-deletes the user account including all completion records, xAPI statements, and certificates.

Root cause: The SCIM DELETE operation is mapped to hard-delete in the LMS rather than account suspension. SCIM 2.0 (RFC 7644 §3.6) defines DELETE at the resource level, but LMS platforms should implement this as account deactivation, not data deletion, to preserve compliance training records.

Fix: Before enabling SCIM provisioning in production, test a DELETE operation in a staging environment and verify the LMS response. If the LMS hard-deletes, contact the vendor, most support a PATCH active: false approach for deactivation, or a configurable DELETE behaviour. Configure SCIM to send PATCH {“active”: false} rather than DELETE if hard-delete behaviour cannot be changed. Reference: SCIM 2.0 RFC 7644.

Issue 6: JIT Provisioning Creates Duplicate Accounts

Symptom: After enabling JIT provisioning, learners have two LMS accounts, the pre-existing manually created account and a new SSO-provisioned account with no training history.

Root cause: JIT matching logic uses the SAML NameID or OIDC sub claim to look up existing accounts, but the pre-existing accounts were created with a different identifier (e.g., a username string vs. an email address). The LMS treats them as different users.

Fix: Before enabling JIT provisioning, align the LMS’s existing account identifiers with the NameID format the IdP will send. For SAML: configure the IdP to send NameID in emailAddress format; batch-update LMS usernames to match email addresses. For OIDC: confirm the LMS uses email (not sub) as the account-match key, since sub values differ between IdPs and will not match existing accounts. Complete this alignment before enabling JIT, not after.