IAM (Identity and Access Management) is how systems answer two HUGE questions: who are you (authentication, "AuthN"), and what are you allowed to do (authorization, "AuthZ"). This article will answer those questions.
Authentication proves who you are, which is your identity. It can be a password, a passkey, a certificate or something else. Authorization decides what you can do once you are authenticated. Can you read a file, install doom/minecraft, browse a sus webpage on a school computer. All of the online world is gated by these two concepts, and a lot of confusion comes from mixing them up: OAuth 2.0, for instance, is an authorization framework, not an authentication protocol. Duh. OIDC (§5) had to be built on top of it to pass claims and stuff that allow you to be authorized to do things.
The classic pattern: the user logs in with a password, the server then creates a session and hands the browser a cookie which contains a session ID. The browser sends that cookie back with every request; the server looks it up to know who's asking.
An API key is a long standing static secret string that is sent with every request, to identify the calling application. HTTP Basic Auth sends a username and password, which is base64-encoded (not encrypted), on every request.
OAuth 2.0 is an authorization framework that lets a user grant one application limited access to their data on another service, without giving a password to the first app. It is built on trusting the identity provider (IDP).
| Role | Meaning |
|---|---|
| Resource owner | The user |
| Client | The app requesting access |
| Authorization server | Issues tokens after the user approves |
| Resource server | The API holding the user's data |
The most common flow (authorization code) works like this:
What OAuth 2.0 does not define: who the user is. It only proves the client was granted access. OIDC does the next part.
OpenID Connect is an identity layer which is built on top of OAuth 2.0 framework. It adds an ID token (a JWT, see §6) that says exactly who logged in, which is issued alongside the regular access token in the same flow.
This is the standard behind prettymuch every of the "Sign in with Google / Microsoft / Apple" buttons. The client gets both an access token to call APIs on the user's behalf and an ID token to know who the user actually is.
A JWT (JSON Web Token, pronounced "jot") is s three part string of text. It has
a header, claims - user ID/expiry/issuer/something else, and a signature: base64(header).base64(payload).signature.
Anybody can decode and read a JWT's payload; it's not encrypted or anything, just signed. The signature is what lets a resource server verify the token wasn't tampered with, without calling back to the issuer for each request.
RFC 8693 (OAuth 2.0 Token Exchange) is the IETF standard for a specific chained service problem: Service A holds a token proving the user authenticated to it, and now needs to call Service B as that same user, not as itself, and without the user needing to log in again. It defines a generic grant type where a client presents one token and gets back another, optionally narrowed in scope or re-targeted to a new audience, while preserving (or explicitly delegating) the original identity. This is used in AI agents a lot.
On-Behalf-Of (OBO) is Microsoft's implementation of RFC 8693 in Azure AD/Entra ID — one concrete instance of the standard, not a separate flow. Other identity providers implement the same RFC 8693 exchange under their own names, so "token exchange" is the general term to reach for; OBO is what you'll see it called if you're specifically in the Microsoft ecosystem.
SAML (Security Assertion Markup Language) is an older, XML-based alternative to OIDC that does the same thing. allows for single sign-on. This one is usually relegated to human logins. Unlike OIDC which is commonly used for both human and machine. An identity provider (IdP) issues a signed XML assertion about a user; a service provider (SP) trusts assertions from that IdP and logs the user in without a separate password. Its trust!
Super common in enterprise/corporate SSO. Think when you get logged into an app without a password on your school computer. It trusts your login to the computer itsself in that case. (it predates OAuth 2.0/OIDC and is huge in enterprise identity providers). OIDC's JSON-over-HTTP model is simpler to implement nowadays and usually works better.
Normal TLS only proves the server identity to the client. Mutual TLS does both. Both sides have to present X.509 certificates, and both will verify each other before any data moves. Common for service-to-service auth inside a private network or between organizations with a pre-established trust relationship, where there's no human around to click through a login screen.
WebAuthn is a W3C standard for public-key-based login: your device generates a key pair, keeps the private key in some secure hardware (a TPM, a phone's secure enclave), and only ever sends the public key to the server. Passkeys are the consumer-facing product name for WebAuthn credentials that sync across a user's devices.
Theres no shared secret transmitted or stored server-side so this approach is actually pretty resistant to phishing and to the password-database breaches that plague the older approaches in §2–3.
| Situation | Typical choice |
|---|---|
| User logging into a website/app | OIDC (or passkeys directly) |
| App accessing a user's data on another service | OAuth 2.0 |
| Enterprise single sign on to corporate apps | SAML |
| Service A calling Service B as the current user (AI Agents) | OBO / token exchange (RFC 8693) |
| Service-to-service, no human present | mTLS or scoped API keys |
| Passwordless, phishing-resistant login | Passkeys / WebAuthn |