IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
JIT provisioning & account linking
Sam's partner company just got single sign-on access to your app. Sam logs in at his own company's IdP and arrives at your app. Your app has never heard of him. Your goal: choose how to handle a first login, and link accounts without opening a hole.
- A first federated login can be pre-provisioned, JIT-created or invite-only.
- JIT makes an account at first login, from the assertion.
- Never link accounts by an unverified email claim. That is account takeover.
- Link only with a verified email from a trusted issuer plus a fresh login.
- JIT never deletes. Dormant accounts pile up, so run access reviews.
First login: three answers
A federated user arrives for the first time and has no local account. There are three sensible ways to handle this.
📋 Pre-provision (SCIM)
The account exists before Sam arrives. His company's directory pushes users to you in advance, using SCIM (RFC 7644). You get the most control and do the most setup. See the SCIM lesson.
⚡ JIT provisioning
Just-in-time (JIT) provisioning makes the account on the spot, at first login. It uses the facts in the assertion: name, email, group. It is fast, but you trust whatever the assertion says.
✋ Invite-only
Say no by default. Unless an admin has invited this person, the first login is refused. An unexpected assertion gets nowhere. But someone must invite every user first.
Account linking
What if the same person comes through two doors? Priya signed up months ago with an email and password. Today her company turned on SSO, and she signs in through the new door. Account linking joins the two logins into one account.
The key question is: what proves they are the same person? The obvious answer is "the same email address". That is also the dangerous one.
a gym with a company tie-up. On your first visit, the desk makes you a member from your company ID. That is JIT. If you already have a personal membership, the desk must not merge the two just because an ID shows your phone number. Anyone can print a fake ID. The desk should ask you to log in to the old membership first.
Linking by an unverified email claim is a classic account takeover bug. An attacker sets up a look-alike IdP. It says email: victim@example.com. Your app links the attacker's login to the victim's account, and no password was needed. The issuer is the IdP that signed the assertion. Check that you trust it, and that it verified the email.
Ask for proof before joining accounts. Two safe patterns:
| Safe linking pattern | What it needs |
|---|---|
| Verified email + re-login | Link automatically only if a trusted issuer marked the email as verified. Also require a fresh login to the existing account. Proving control of the old account is the real gate. |
| User-confirmed link | Do not link automatically. Let the user, already signed in, choose "connect my SSO login to this account". |
JIT creates but never deletes
JIT is good at the joiner moment and absent at the leaver moment. Nothing tells your app when a person leaves the partner company. So dormant accounts pile up: valid logins for people who no longer belong. This is deprovisioning missing, from the lifecycle lesson. That is why JIT shops run regular access reviews.
Go deeper: closing the leaver gap
Two standards help. With SCIM, the partner's directory can also deactivate Sam: it sends a PATCH that sets active to false (RFC 7644). Group changes go through the Groups resource, because a user's groups list is read-only (RFC 7643).
The Shared Signals Framework (from OpenID, final in 2025) helps too. The IdP can send a signed event such as "this account was disabled". Your app can then end the session at once. These tools need the partner to support them. JIT alone does not.
Now play it. The lab runs Sam's first login step by step. Try four what-ifs, then set a policy and meet three strangers.
🧪 Interactive lab — enable JavaScript to play with this one.
Check an assertion's identity claims, including whether the email is really verified, with ID Token Check. Or grade a pasted SAML response for forgery tricks with SAML Response Check.