What Is an LTI® Key?
The short answer
An LTI® key — properly a consumer key — was half of a key and secret pair in LTI® 1.1. Both sides held the same secret and used it to sign launches. LTI® 1.3 removed it. There is no shared secret any more, and most published answers to this question describe a version deprecated in 2022 by 1EdTech Consortium, Inc.
What the old key was
Under LTI® 1.1 an administrator was given two strings: a consumer key identifying the platform, and a shared secret. The tool held the same pair. Every launch was signed with the secret using OAuth 1.0a, and the tool verified by computing the same signature.
It was simple, which is why it lasted, and it had three problems that eventually ended it.
The secret had to be transported to be shared. It arrived by email, in a ticket, or in a spreadsheet, and it stayed valid wherever it landed.
It was rarely rotated. Rotating meant both sides changing at the same moment, so in practice nobody did.
Anyone holding it could mint launches. The secret both proved identity and signed messages, so a leak meant an attacker could impersonate the institution and claim to be any user in it.
What replaced it
LTI® 1.3 splits the two jobs the old key was doing.
Identity is now a client ID, plus an issuer naming the platform and a deployment ID naming the installation. None of these are secret. A client ID identifies your tool; on its own it does nothing.
Signing now uses asymmetric keys. The platform signs each launch with a private key it never discloses, and publishes the matching public key at a key set URL — a JSON Web Key Set. The tool fetches that public key and verifies.
The difference that matters: a public key is worth nothing to an attacker. There is no shared value to leak, and either side can rotate its keys without coordinating with the other.
| LTI® 1.1 | LTI® 1.3 | |
|---|---|---|
| Identity | Consumer key | Client ID + issuer + deployment ID |
| Signing | Shared secret, OAuth 1.0a | Private key, published key set |
| Secret in transit | Yes | No |
| Rotation | Both sides at once | Either side, independently |
| If leaked | Attacker can forge launches | Nothing to leak |
So what do people mean when they ask for a key?
Usually one of four things. It is worth asking which.
"Give me the values to set you up." They mean the exchange — client ID, deployment ID, issuer and your URLs. The habit of calling that bundle "the key" survived the version change.
A Canvas developer key. Canvas calls its registration record a developer key, and it is where the client ID comes from. Real, current, and specific to Canvas.
An actual 1.1 key and secret. Some platforms still offer 1.1, and some tools still only support it. If a customer hands you a key and a secret, that is what this is.
Your tool's own API key. Unrelated to LTI®, and worth separating explicitly in the conversation before someone pastes the wrong one into the wrong box.
If you have been given a key and secret
That customer is on LTI® 1.1. It still works on many platforms, but it is deprecated, gains no new services, and has the security properties described above.
Two things to check. Does their platform support 1.3? Most do, and the administrator may simply not have been asked. And if you are planning to move them, read migrating from LTI® 1.1 to 1.3 first — the user identifiers differ between versions, so a straight switch can make returning users look like new ones.
LTIAAS supports LTI® 1.1 where an institution genuinely cannot move yet. It is off by default, because new integrations should be on 1.3, and enabled per account on request. Ask us if that applies.
What you actually need for a 1.3 integration
No key, no secret. From the administrator: issuer, client ID, deployment ID and the platform's three endpoints. From you: login, launch and key set URLs. That is the whole exchange, and the configuration fields article covers each one.
Common questions
What is an LTI® key?
In LTI® 1.1 it was half of a key and secret pair shared between the platform and the tool, used to sign launches. LTI® 1.3 removed it — there is no shared secret, and signing uses public and private keys instead.
Where do I get an LTI® key?
For a 1.3 integration you do not. You exchange a client ID, a deployment ID and an issuer with the administrator, and each side publishes a public key set. If someone asks you for a key and secret, they are describing a 1.1 setup.
Is a client ID the same as an LTI® key?
It is the nearest equivalent, but it is not a secret. A client ID identifies your tool and is not sensitive on its own. The old consumer key came with a secret that could sign launches; a client ID cannot.
I have an LTI® key and secret from a customer. What now?
They are on LTI® 1.1. It still works on many platforms but is deprecated and gains no new services. Check whether their platform supports 1.3 — most do — and plan the move.
Next
- Every LTI® 1.3 configuration field explained
- LTI® 1.3 vs LTI® 1.1 — everything else that changed
- The LTI® 1.3 security model
