LTI Integration: The Definitive Implementation Guide for LMS Administrators and Developers (2026)

If you have inherited a broken LTI 1.3 tool launch, or you are standing up your first LTI Advantage integration and watching a blank iframe where the tool should be, this guide is written for you. It covers the LTI 1.3 / LTI Advantage specification (1EdTech, final release 2019, incrementally updated through 2025), the full OIDC launch sequence, service configuration for AGS and NRPS, per-platform implementation notes, and the six errors that account for the vast majority of production failures.

Previous versions of LTI (1.0 and 1.1) used OAuth 1.0a HMAC-SHA1 signatures, a shared-secret model that carried meaningful replay and substitution risks. LTI 1.3 replaces that entirely with OpenID Connect (OIDC) + RSA-256 signed JSON Web Tokens (JWTs) + OAuth 2.0 access tokens. If your institution is still deploying LTI 1.1 tools, those specifications are now formally deprecated by 1EdTech and should be treated as a migration backlog item.

LTI 1.3 and LTI Advantage: What the Specification Actually Specifies

The LTI Advantage is not a separate version, it is a bundle of four specification documents, all predicated on LTI 1.3 Core security:

LTI Core 1.3, OIDC-based SSO launch (the replacement for LTI 1.1 Basic Launch)

• Assignment and Grade Services (AGS), REST API for creating line items and posting scores to the LMS gradebook asynchronously
• Names and Roles Provisioning Services 2.0 (NRPS), REST API for fetching full course rosters, including users who have never launched the tool
• Deep Linking 2.0, bidirectional content selection flow, replacing the deprecated Content Item Message from LTI 1.1

The Five-Step OIDC Launch Flow

Every LTI 1.3 launch follows the same OIDC implicit flow. Understanding every hop is essential for diagnosing failures, most errors occur at steps 2 or 4.

1. Initiation (Platform → Tool): User clicks an LTI link. The LMS POSTs an OIDC Login Initiation to the tool’s registered oidc_initiation_url, includingiss, login_hint, target_link_uri,and lti_message_hint.
2. Authentication Request (Tool → Platform): The tool redirects back to the platform’s authorization_endpoint with response_type=id_token, scope=openid, a cryptographic nonce, and a state value stored in a first-party cookie to prevent CSRF.
3. JWT Delivery (Platform → Tool): The platform builds an id_token JWT containing the LTI payload claims, signs it with its RSA-256 private key (minimum; per IMS Certification Guide, symmetric cryptosystems are expressly forbidden) and POSTs it back to the tool’s redirect_uri.
4. JWT Validation (Tool): The tool fetches the platform’s public JWKS from the registered jwks_uri, locates the key by kid, validates the RSA signature, and asserts claims: iss, aud, exp, iat, nonce, deployment_id.
5. Service Token Acquisition (Tool → Platform OAuth 2.0): If AGS or NRPS is needed, the tool uses the JWT Bearer Client Authentication flow, constructing a signed client assertion JWT and posting it to the platform’s token_endpoint , to obtain a scoped Bearer token.

LTI Advantage LMS Compatibility Matrix (2026)

Certification status reflects 1EdTech LTI Advantage certified implementations as of Q1 2025. “Partial” indicates the service is supported but with known interoperability gaps (e.g., Dynamic Registration token-encoding bugs in Blackboard, NRPS pagination differences in Sakai). Always verify against your specific platform version.

Notes: Dynamic Registration (RFC 7591) is an optional extension that allows tools to self-register via a URL rather than manual credential exchange. Canvas and D2L implementations are most reliable. Moodle 4.3+ supports it as a tool (consumer) but interoperability when acting as a platform against other LMSs has known issues (MDL-81409). Caliper Analytics Connector is supported by Canvas and D2L Brightspace as part of the LTI Advantage Data bundle.

Implementation Steps: Registering an LTI 1.3 Tool Across Major Platforms

All platforms require the same six credential artifacts exchanged out-of-band during registration. The tool provides: OIDC Initiation URL, Redirect/Target Link URI, JWKS URL (public key endpoint). The platform provides: Issuer URL, Client ID, Deployment ID, JWKS URL, Auth Endpoint, Token Endpoint.

Canvas (Instructure)

1. Admin > Developer Keys > + LTI Key , configure all tool endpoints and scopes. Canvas calls its JWKS URL the “JWK Method” and defaults to Auto-rotation.
2. Set Redirect URIs exactly , Canvas performs strict match including trailing slashes. A common failure is a trailing-slash mismatch.
3. Admin > Settings > Apps > + App , select “By Client ID”. Note the Deployment ID shown here; it differs from the Client ID.
4. For AGS, explicitly grant scopes: https://purl.imsglobal.org/spec/lti-ags/scope/lineitem and score under Additional Settings on the Developer Key.

Moodle 4.x

1. Site Administration > Plugins > Activity Modules > External Tool > Manage Tools. Select “Tool configuration by URL” if the tool supports Dynamic Registration, or “Manual” for static credential exchange.
2. Moodle generates a per-deployment platform_id (its site URL), a unique client_id, and a Deployment ID. Moodle’s token endpoint is at /mod/lti/token.php.
3. Enable mod_lti | ltiservice_gradebookservices in plugin settings for AGS support. Without this toggle, the AGS claim is omitted from the JWT even if the tool requests it.

D2L Brightspace

1. Admin Tools > External Learning Tools > Manage External Learning Tool Links > New Link. Brightspace calls its Auth Endpoint the “OpenID Connect Login Initiation URL”.
2. D2L requires all Redirect URIs to match against a whitelist. A Redirect URI mismatch produces an opaque “Unable to connect” error. The OIDC Initiation URL and Redirect URI must use HTTPS , HTTP is rejected at the platform level.
3. For Caliper Connector support (part of LTI Advantage Data), enable “Send Caliper Events” in the tool link configuration. D2L is one of two platforms (with Canvas) that support this service.

Blackboard Ultra

1. Administrator Panel > LTI Tool Providers > Register LTI 1.3/Advantage Tool. Blackboard uses the term “Application ID” in place of Client ID in some UI versions.
2. Blackboard’s aud claim handling has historically been platform-version dependent. Pre-2023 builds sent aud as a string; post-2023 they support array format. If your tool validates aud strictly as an array, test against the target version.
3. Dynamic Registration has a known URL-encoding bug in Blackboard (related to registration token transmission). Manual registration is the reliable path for Blackboard until confirmed fixed in your version.

Common LTI 1.3 Errors and Specific Fixes

1. Invalid IAT/EXP, Launch Expired or Already Consumed

Symptoms: Canvas returns Lti::IMS::InvalidLaunch (no payload found in cache). YuJa surfaces Invalid IAT and/or EXP values in the LTI 1.3 Launch request.

Root causes: (a) Tool’s nonce store (Redis, DB) has a TTL shorter than the JWT’s lifetime. (b) Clustered tool nodes are not sharing nonce state. (c) Server clock skew exceeds the platform’s tolerance (usually ±5 minutes). (d) The tool is attempting to reuse a launch URL (nonces are single-use).

• Fix (a/b): Use shared, persistent nonce storage (Redis with expiry = JWT exp – JWT iat + buffer). Never use in-process memory in multi-node deployments.
• Fix (c): Synchronize tool server time via NTP. Check with ntpstat or chronyc tracking.
• Fix (d): Ensure each launch generates a fresh OIDC initiation request; never cache or share launch URLs.

2. KID Not Found / JSON::JWK::Set::KidNotFound

Symptoms: Deep Linking returns {“errors”:{“jwt”:[{“type”:”JSON::JWK::Set::KidNotFound”}]}}. JWT validation fails intermittently.

Root cause: The tool’s JWKS endpoint returns a key whose kid doesn’t match the kid in the JWT header. Usually caused by (a) key rotation that wasn’t propagated, (b) JWKS served as an array without “keys” wrapper, or (c) JWKS endpoint returns wrong Content-Type.

• Fix: Ensure JWKS response has Content-Type: application/json and uses the standard {“keys”: […]} wrapper format.
• Verify kid values match between the JWT header and the JWKS entry. If rotating keys, keep the old public key in the JWKS for at least one full JWT lifetime after rotation.

3. Blank / Blocked iFrame , SameSite Cookie Rejection

Symptoms: Tool renders blank in the LMS iframe. Browser console shows Set-Cookie was blocked because it had the ‘SameSite=Lax’ attribute but came from a cross-site response.

Root cause: LTI 1.3’s OIDC flow requires the tool to read back a state cookie that was set during the initiation step. When the tool is embedded in an iframe, third-party cookie restrictions in Safari (ITP) and Chrome (CHIPS) block this cookie.

• Fix: Set session cookies with SameSite=None; Secure , but this alone is insufficient in modern Safari.
• Preferred fix: Implement the 1EdTech-specified cookie-less OIDC flow using storage_target parameter (posted to a first-party page via postMessage), or use the tool in a new tab/window launch mode.
• Interim fix: Configure the LMS to launch tools in a new window where first-party cookie context is preserved.

4. AGS Score Submission Returns 401 / 403

Symptoms: Tool posts to the AGS score endpoint and receives 401 Unauthorized or 403 Forbidden.

Root causes: (a) OAuth 2.0 Bearer token requested without the correct scope. (b) Bearer token is expired (they are typically short-lived, 1 hour). (c) The tool’s client assertion JWT is missing the deployment_id claim, which became a required field per the 2024 LTI 1.3 Core specification update. (d) The LMS Developer Key does not have the AGS scope granted.

• Fix (a/d): On the LMS side, explicitly enable scopes: https://purl.imsglobal.org/spec/lti-ags/scope/lineitem and /scope/score. On the tool side, include all required scopes in the token request.
• Fix (b): Cache Bearer tokens and check expiry before each service call. Re-request when expired rather than reusing stale tokens.
• Fix (c): Include deployment_id claim in the client assertion JWT per the updated 2024 specification.

5. Redirect URI Mismatch on Tool Registration

Symptoms: Platform returns redirect_uri_mismatch or invalid_client during the OIDC auth step. D2L typically shows “Unable to connect to [tool domain]”.

Root cause: The Redirect URI registered in the LMS doesn’t exactly match the URI submitted in the OIDC auth request, including protocol, port, path, and trailing slash.

• Fix: Compare the registered URI character-by-character with the runtime URI. Common mismatches: http vs https, port 443 vs no-port, trailing slash presence. Both Canvas and D2L perform strict string comparison.
• If using multiple environments (dev/staging/prod), register all redirect URIs explicitly, most platforms support multiple redirect URIs per registration.

6. NRPS Returns Empty Member List or Missing Users

Symptoms: NRPS call to context_memberships_url returns fewer users than enrolled, or omits instructors.

Root causes: (a) NRPS response is paginated (Link header with rel=”next”) and the tool only reads the first page. (b) Moodle’s mod_lti | ltiservice_gradebookservices plugin is disabled, which also suppresses NRPS. (c) The user has not yet been enrolled in the LMS course roster at time of request.

• Fix (a): Implement pagination following the Link: rel=”next” HTTP header across all NRPS responses. Never assume a single response is complete.
• Fix (b/c): Verify plugin settings and re-test after confirming full enrollment sync from SIS.