Protocol practice · Guide
Which protocol?
Start from what you're trying to do. Each answer says why, and links to the lab where you run it, one message at a time.
What are you trying to do?
- Let people sign in to your appOpenID ConnectYour app learns who signed in, from an ID token it checks itself. It’s built on OAuth, so the same flow can also get an access token for your API.Practice OpenID Connect
- Give staff single sign-on to company appsSAML, or OpenID ConnectMost enterprise SaaS apps accept SAML; newer ones often prefer OpenID Connect. Use what the app supports, and OpenID Connect when it supports both.Practice SAML
- Let an app act for a userOAuth 2.0The user grants a limited access token, like “read my calendar”, and the app never sees their password. On its own, OAuth doesn’t say who the user is.Practice OAuth
- Create and remove accounts in other appsSCIM 2.0The standard API your identity platform calls when people join, move and leave, so access follows the person. It doesn’t sign anyone in.Practice SCIM
- Sign in on a Windows domainKerberosOne sign-in to the domain, then tickets for file shares and other services. It’s how Active Directory signs people in on the network.Practice Kerberos
- Run customer sign-in on a platformA hosted identity platform MembersWhere the protocols meet real settings: callbacks, audiences, claims and refresh tokens. The lab uses Auth0.Practice Auth0
Often confused
- OAuth or OpenID Connect?OAuth answers “what may this app do?”. OpenID Connect adds “who signed in?”. Treating an OAuth access token as proof of sign-in is one of the classic mistakes: use the ID token.Practice OAuthPractice OpenID Connect
- SAML or OpenID Connect?Both give single sign-on. SAML posts signed XML through the browser and is everywhere in enterprise SaaS. OpenID Connect uses JSON tokens and also suits mobile apps and APIs. New build: OpenID Connect. Existing app: whatever it supports.Practice SAMLPractice OpenID Connect
- SCIM or sign-in?SAML and OpenID Connect sign people in. SCIM makes sure their account exists, is right, and is switched off when they leave. Most apps need both, because sign-in alone leaves accounts behind.Practice SCIMPractice SAML
They work together
A typical company app uses three of them at once.
Identity provideryour company’s directory
The appSaaS, or your ownThe app’s accountscreated, changed, switched off
Access: an OAuth tokenAn APIcalendar, files, dataSide by side
| Protocol | Answers | Hands over | Travels | Usual home |
|---|---|---|---|---|
| OAuth 2.0 | What may this app do? | An access token | Browser redirects, then server to server | APIs, third-party apps |
| OpenID Connect | Who signed in? | An ID token (a JWT) | Like OAuth | Web and mobile sign-in |
| SAML 2.0 | Who signed in? | A signed XML assertion | Through the browser | Enterprise single sign-on to SaaS |
| SCIM 2.0 | Does the account exist, and is it right? | REST calls in JSON | Server to server | Provisioning |
| Kerberos | Who is this, on the network? | Tickets | Client to the domain controller, then to services | Windows domains, on-premises |
Not here yet: services calling APIs with no user (OAuth client credentials, workload identity federation). They're in Coming later on the practice page.