Every LTI® 1.3 Configuration Field Explained
The short answer
Setting up an LTI® 1.3 integration means exchanging about eight values with an administrator. Half of them you generate and half the platform generates, which is the single thing that makes the process confusing. Each field below is listed with which side it comes from and what it is for.
The field names come from the specification and its implementation guide, both published by 1EdTech Consortium, Inc.
The exchange goes both ways
Most setup guides read as a linear list of boxes to fill, which hides the shape of what is happening. There are two handovers:
You give the platform the URLs where your tool can be reached, and a way to verify your signatures. None of these exist until you decide them.
The platform gives you back the identifiers it has minted for your tool. None of these exist until the administrator creates the registration.
A setup that stalls halfway usually stalled between those two handovers — one side sent their values and never received the other's.
What you give the platform
| Field | Also called | What it is |
|---|---|---|
| Login initiation URL | OIDC login URL, initiate login URI | Where the platform sends the browser to start a launch. The first step, before any token exists. |
| Launch URL | Redirect URI, target link URI | Where the platform POSTs the signed ID Token. Must also be registered as an allowed redirect URI. |
| Key set URL | JWKS URL, public keyset URL | Where you publish the public keys the platform uses to verify your signatures on service calls. |
| Deep linking URL | Content selection URL | Where a content-selection launch goes, if you support deep linking. Often the same as the launch URL. |
Two things about these that cause real failures.
Redirect URIs are matched literally. A platform compares the launch target
against its registered list as an exact string. https://tool.example.com and
https://tool.example.com/ are different values. Brightspace is strictest about
this, and the resulting error names the redirect URI without explaining that a
trailing slash is the difference.
Your key set URL has to stay reachable. It is fetched during service calls, and if it stops resolving, every institution's integration breaks at once. It looks like a total outage and it is a DNS or certificate problem.
What the platform gives you
| Field | Also called | What it is |
|---|---|---|
| Issuer | iss, platform ID | A string identifying the platform. Arrives on every launch as the iss claim. |
| Client ID | Developer key ID, application ID | Identifies your tool to that platform. One per registration. |
| Deployment ID | deployment_id | Identifies one installation of your tool within the platform. |
| Authentication endpoint | OIDC auth URL | Where you redirect the browser during a launch. |
| Access token endpoint | Token URL, OAuth2 URL | Where you exchange a signed assertion for an access token to call services. |
| Platform key set URL | Platform JWKS | Where the platform publishes the keys you verify launches against. |
The three identifiers, and why they are not interchangeable
This is where most of the confusion lives.
Issuer identifies the platform. Crucially, it is not necessarily the
platform's URL. Canvas frequently sends https://canvas.instructure.com even
for institutions on their own domain. A registration keyed on the institution's
hostname will never match. If a Canvas setup looks correct and nothing works, try
both values — this single fact accounts for a large share of Canvas support
tickets.
Client ID identifies your tool to that platform. Two different tools at the same university have different client IDs.
Deployment ID identifies an installation. One client ID can have several — a tool installed at the account level and again in a sub-account.
The important consequence: a registration is matched on issuer and client ID together, not on issuer alone. A tool serving many institutions will see the same issuer from several of them, and looking up by issuer alone will hand one institution another's configuration.
On Blackboard this stops being theoretical. Its multi-tenant model lets several institutions share a registration, arriving with the same issuer and the same client ID, and the deployment ID is the only thing telling them apart. If you support Blackboard, store and check it from the start — treating it as a formality is a data separation bug.
The naming differs by platform
The specification names these fields one way and the admin screens name them another. Same values, different labels:
| Specification | Canvas | Moodle | Blackboard |
|---|---|---|---|
| Client ID | Developer key / Client ID | Client ID | Application ID |
| Login initiation URL | OpenID Connect Initiation Url | Initiate login URL | Login URL |
| Launch URL | Target Link URI | Redirection URI | Tool launch URL |
| Key set URL | Public JWK URL | Public keyset | Tool JWKS URL |
When a vendor's instructions and an administrator's screen disagree, they are almost always the same field under two names.
Fields you can usually skip
Custom parameters let the platform send extra values on every launch, set per placement by the administrator. Useful, but not required to get a launch working — add them once the basics work.
Privacy level controls how much personal data the platform sends. Worth setting deliberately rather than leaving at the default: the specification does not require a platform to send a name or an email, and many are configured not to. Request the minimum you need, and design for its absence.
Avoiding the exchange entirely
Every field above is one that can be typed wrong. Dynamic registration removes the exchange: the administrator pastes one URL and the two systems agree everything else between themselves. Where the platform supports it, ask for it first.
Where LTIAAS fits
LTIAAS holds the tool half of this. The login, launch and key set URLs you give the administrator are on your LTIAAS subdomain, so you do not publish a key set, manage a key pair, or handle the OIDC endpoints. The values the platform returns are stored per registration, and matched on issuer and client ID together.
The step-by-step for each platform is in the LMS setup guides, and the manual registration guide walks the exchange field by field.
Common questions
What is the difference between client ID and deployment ID?
The client ID identifies your tool to the platform — one per registration. The deployment ID identifies a particular installation of that tool within the platform, and there can be several under one client ID. On most platforms it is a formality; on Blackboard it distinguishes separate institutions.
What is the issuer in LTI®?
A string identifying the platform, sent as the iss claim on every launch. It is not necessarily the platform's URL — Canvas commonly sends https://canvas.instructure.com even for institutions on their own domain.
Which fields do I generate and which does the LMS?
You generate the login, launch and key set URLs and give them to the administrator. The platform generates the issuer, client ID and deployment ID and gives them back. It is an exchange in both directions, which is why half a setup often gets missed.
Why does my registration not match the launch?
Almost always the issuer or a URL. A registration is matched on issuer and client ID together, so if the platform sends a different issuer than you registered, nothing matches. Trailing slashes on URLs are the other common cause.
Next
- LTI® dynamic registration explained — skipping the exchange
- What is an LTI® key? — why 1.3 has no key and secret
- The LTI® 1.3 security model — what these values are protecting
