LTI 1.3 — launching Miatz from your LMS
Register your learning platform once, and your people reach Miatz courses and exams from inside the LMS they already use — without Miatz ever holding a shared secret.
- Learners launch from the LMS they already live in
- No shared secret is ever stored — LTI 1.3 is key-based
- An unregistered platform is refused before anything else happens
- A launch can never grant someone more access than you gave them
One registration, then launches just work
Register your platform's issuer, client id, deployment id and key URL, set it active, and your people can open Miatz from inside the LMS.
No secret to leak
LTI 1.3 is key-based. The platform signs each launch; Miatz verifies against the keys that platform publishes. There is no client secret, no shared secret, and no place in the schema to store one.
A launch cannot mint privilege
An LMS role is an assertion by a third party, so Miatz caps what it can become. The most a launch produces is a read-shaped role; anything unrecognised becomes a learner; and no role that can write anything is reachable from a launch at all.
A launch may create a membership for someone who already has a Miatz account with a verified email. It never creates a person, and it never changes an existing membership — so an LMS role change can't rewrite your own access decisions.
The kill switch
Set the registration to suspended. Only an active registration resolves a launch.
Frequently asked
What do I need from my LMS?
Four public values: the platform's issuer, the client id it assigned to Miatz, the deployment id, and the URL where it publishes its keys — plus its login and token endpoints. Nothing secret.
Why is there no client secret field?
Because LTI 1.3 does not use one. The platform signs each launch with its own key and publishes the matching public key; Miatz verifies against that. There is deliberately no place in the schema to put a secret, and the migration fails if one is ever added.
Can a launch make someone an admin?
No. An LTI role is an assertion by someone else's system, so it is capped: the most a launch can produce is a read-shaped role, and anything unrecognised becomes a learner. Roles that can write — owner, org admin, enablement, author, reviewer, proctor — can never be granted by a launch. You promote people yourself, in the portal.
What happens for someone with no Miatz account?
The launch is refused with an explanation. A launch can create a membership for someone who already has a Miatz account and a verified email, but it never creates the person, and it never modifies an existing membership — not its role, not its status.
Does the launch sign me in?
No. It establishes who the platform says you are; your browser still needs its own Miatz session, so you are sent to sign in and then straight on to the right place. If the browser is signed in as somebody else, the launch is refused rather than crossing identities on a shared computer.
A launch failed with a message about cookies. Why?
The platform's reply is a cross-site form post, so the launch needs a cookie Miatz set at the start of it. Browsers that block third-party cookies drop it, and the launch fails closed rather than skipping the check. Open Miatz directly, sign in, and use the link again.
How do I turn an integration off?
Set the registration to suspended or archived. Only an active registration resolves a launch, so that one change stops it immediately.
Related guides
Four deeper ways to establish that someone can actually do the work: an adaptive viva, in-product Journey runs, LTI launches from your LMS, and partner tiers that follow certified headcount.
ReadRun your organization's people, teams, invitations and domains from one control plane.
Read