Authentication, SSO, and OAuth.
Two questions sit under almost every piece of software a person touches: who are you, and what are you allowed to do. Here is the field that answers them, in plain language.
Authentication proves who you are. Authorization decides what you may do. They sound alike, they are not, and most security trouble starts with mixing them up. Single sign-on lets you prove yourself once to a trusted login and have every connected app honor that one proof. OAuth 2.0 lets you grant a narrow, revocable slice of access to something acting for you, without ever handing over a password. OpenID Connect adds the part that says who logged in. We walk it the way the field is built: what it is, why it is hard, how it works, what it unlocks, and where it is heading. The standards behind each idea are linked, so you can read the source yourself.
Two different questions, named precisely.
Authentication (AuthN) proves who you are. Authorization (AuthZ) governs what you may do. Keeping them crisp is already half the subject.
Single sign-on, or SSO, is one authentication session honored across many independent applications. You prove yourself once to a trusted party, and each app trusts that proof instead of running its own login. Three roles run through the whole field. The identity provider (IdP) authenticates you and issues a signed statement. The service provider or relying party (SP/RP) consumes it. The user-agent, usually a browser, shuttles between them.
The landscape, presented neutrally rather than as endorsements: Kerberos is the classic single sign-on inside a network. SAML 2.0 carries XML assertions and has long been common in enterprise web SSO. OAuth 2.0 is a framework for delegated authorization. OpenID Connect is an identity layer on top of OAuth 2.0.
Here is the distinction worth teaching, because it is the field's most common mistake. OAuth 2.0 is an authorization framework: it issues access tokens for reaching resources. It is not, by itself, a login protocol. OpenID Connect adds the authentication answer, an ID token that states who logged in. Using a plain OAuth access token as proof of who logged in is a documented anti-pattern, and OpenID Connect exists precisely because OAuth alone does not answer "who."
- Sign in with the identity provider
The user authenticates with the organization’s sign-in service.
- The app verifies the identity assertion
It establishes which user is signing in.
- Evaluate the requested access
Identity alone does not grant every permission.
Passwords do not scale, and trust is being stretched across boundaries.
Sharing a password gives away everything, forever, with no scoping and no clean revocation. The whole field is a reaction to that.
A shared password is all or nothing.
Hand a tool your password to grant it access and you have given away everything it can reach, with no way to limit the scope and no clean way to take it back. Modern authentication exists to end that habit.
Trust crosses organizations.
One organization's login is trusted by another's app. That trust has to be cryptographically provable and bounded, or it becomes a backdoor rather than a convenience.
Stealing the token steals the access.
Once access lives in a bearer token, whoever holds the token holds the access. That single fact drives exact redirect matching, PKCE, short lifetimes, and sender-constrained tokens, all set out in RFC 9700.
Redirects are an exposed channel.
Authorization codes and assertions travel through the user's browser, which opens the flow to redirect manipulation, mix-up attacks across several authorization servers, and request forgery. Much of the spec text is defense for this channel.
An access token is not a login.
Treating a bare OAuth access token as proof of who logged in is a documented anti-pattern. It answers what you may reach, not who you are. OpenID Connect is the part that answers "who."
"Logged in" is not one thing.
NIST separates identity proofing (IAL), authenticator strength (AAL), and federation strength (FAL) so the strength of a login can be matched to the risk of the situation, rather than treated as one setting.
Prove once, hand out a signed, scoped, revocable token.
Assertions and tokens are the currency. The code travels the browser, the token is fetched in private, scopes decide how far it reaches, and revocation takes it back.
1The currency: assertions and tokens
A signed statement a relying party can verify.
At the center of every protocol here is a signed statement from a trusted issuer: this user authenticated, here are some claims about them. A relying party can verify the signature without ever contacting the user's password store. SAML calls this an assertion, an XML document. OpenID Connect calls it an ID token, a signed JSON Web Token. The envelope differs, the trust pattern is the same.
The load-bearing step is validation. The relying party checks the signature, the issuer, and the audience the statement was meant for, plus when the authentication happened. Skipping that check is how a signed statement meant for one app gets replayed at another.
issuer: trusted-idp
subject: user-184
audience: this-app
expires: 10:30 UTC- Verify signature and issuer
Use the trusted provider and its signing keys.
- Check audience and lifetime
Accept only a token meant for this app and still valid.
2The OAuth 2.0 authorization code flow
The code goes through the browser. The token is fetched in private.
RFC 6749 (Hardt, 2012) sets out the flow most apps use. The app redirects the user to the authorization server. The user authenticates and consents. The server returns a short-lived authorization code through the browser. The app then exchanges that code at the token endpoint, over a back channel, for an access token and often a refresh token. Scopes ride the token and bound what it can do.
The split is deliberate. The thing that travels the exposed browser channel is only a one-time code, not the access itself. The access token is fetched on a direct, private connection, so a code glimpsed in transit is far less useful on its own.
- Redirect
The app sends the browser to the authorization server.
- Authenticate and authorize
The provider signs in the person and obtains the required authorization.
- Return a code
A short-lived authorization code reaches the app.
- Exchange securely
The app exchanges the code at the token endpoint.
3Binding the code to the client: PKCE
Close the gap where a code could be intercepted.
Proof Key for Code Exchange, or PKCE, has the client generate a secret at the start of the flow and send only a hash of it up front, then reveal the secret when it exchanges the code. An intercepted code is useless without that secret, which closes code-interception attacks. RFC 9700 / BCP 240 (Lodderstedt et al., 2025) elevates PKCE to standard practice, requires exact redirect-URI matching, points toward sender-constrained tokens, and deprecates the implicit and password grants.
The theme is hardening the exposed parts of the flow. Exact redirect matching stops a token from being sent to an attacker-controlled address. Sender-constrained tokens bind a token to its holder, so a stolen token does not work on its own.
- Create a verifier
The client generates a random secret for this flow.
- Send a challenge
The authorization request contains a hash derived from that secret.
- Prove possession
At exchange, the client supplies the verifier. The server checks it against the challenge.
4OpenID Connect: the answer to "who"
Same flow, plus an ID token.
OpenID Connect Core 1.0 (Sakimura et al., 2023) runs the same authorization code flow and adds an ID token: a signed JWT whose claims, the subject, issuer, audience, and authentication time, tell the app who authenticated. The access token still answers what you may reach. The ID token answers who you are. Two tokens, two questions, kept separate on purpose.
This is the cleanest place to hold the line the whole page turns on. If an app needs to know who logged in, it reads and validates the ID token. It does not infer identity from an access token, which was only ever about reaching a resource.
ID token
- Question
- Who authenticated?
- Audience
- The client application.
Access token
- Question
- What resource access was granted?
- Audience
- The protected API or resource.
5How enterprise SSO actually shipped
SAML and Kerberos: the same trust pattern, different envelopes.
SAML 2.0 (OASIS Standard, 2005) has long carried web SSO in the enterprise. The service provider redirects to the identity provider, the user authenticates, the IdP posts a signed XML assertion back through the browser, and the service provider validates the signature and opens a session. The same prove-once-then-trust-the-signed-statement shape as OpenID Connect, in an XML envelope.
Kerberos (RFC 4120, Neuman et al., 2005) is the original network single sign-on. A trusted third party, the Key Distribution Center, issues time-limited tickets, so a user authenticates once and then presents tickets to services without re-entering a password and without host-based trust. It is where the single sign-on idea comes from.
- Authenticate
The person proves identity to an IdP or Kerberos KDC.
- Issue proof
SAML supplies an assertion; Kerberos supplies a service ticket.
- Validate at the service
The receiving service checks the proof and applies its own permissions.
6Refresh, expiry, and revocation
Delegated permission can always be taken back.
Access tokens are deliberately short-lived, so a leaked one stops working quickly. A carefully protected refresh token renews them without sending the user back through a full login. Revocation and token rotation are how delegated access is taken back: cut the refresh token, and the renewals stop. This is the machinery behind revoking an integration in one place.
It is also why central lifecycle management matters. When someone leaves, disabling them at the identity provider cuts their access everywhere at once, rather than chasing logins app by app. Honest caveat to close the mechanism on: misconfiguration, not the underlying cryptography, remains the most common way these systems fail.
Time →
Revoking refresh access prevents future renewals. Existing access tokens may remain usable until expiry unless the service checks revocation.
What it unlocks: delegated access without password sharing.
At the field level: one identity across many tools, least privilege by construction, central lifecycle, and interoperability through open standards.
For an enterprise sales buyer, this machinery is behind "log in with your company account," "only see the accounts you own," and "revoke that integration in one click." It is also the vocabulary an IT security reviewer uses to evaluate any SaaS tool. The lines below are examples of how the field works, stated as outcomes, never as claims about how any system we build is put together.
A narrow, revocable scope, not a shared password.
An integration can be granted one named slice of access, for example read a calendar and write a note, and have it revoked in one place, without ever holding the user's credentials.
See only what the signed-in person may see.
As an example of the idea: an assistant that answers only from data the signed-in person is allowed to see, and that keeps one client's material isolated from another's, follows directly from least privilege and audience-restricted tokens.
One identity, central control.
Single sign-on collapses many logins into one trusted authentication, which is both easier to use and a security control: central policy, multi-factor, and deprovisioning in one place when someone leaves.
Open standards, no custom integration per app.
Because these are open standards, a buyer's existing identity provider can front a new tool without a bespoke integration each time. The same vocabulary travels across vendors.
For our actual approach to access, sign-in, and data handling, see Security. This page explains the field. It does not state, claim, or deny which protocols, identity providers, or token types anything we build uses.
The direction the field is heading.
We describe the direction, not a roadmap of our own.
Secure defaults, not options.
RFC 9700 (BCP 240, 2025) makes PKCE, exact redirect matching, and sender-constrained tokens the expected default, and deprecates the implicit and password grants.
Bind the token to its holder.
Approaches such as DPoP and mTLS move the field from bearer tokens toward tokens tied to a specific holder, which shrinks the value of a stolen token.
Public-key credentials at the front door.
Passkeys and WebAuthn / FIDO2 push the login itself toward public-key credentials, which NIST SP 800-63-4 (2025) reflects in its assurance guidance.
Precise language for "how strong."
NIST's separation of proofing (IAL), authenticator strength (AAL), and federation strength (FAL) gives buyers a precise way to say how strong a login is, in place of one-size-fits-all assurance.
Scoped, auditable delegation for non-human callers.
As software agents act on a person's behalf, the OAuth model of scoped, auditable, revocable delegation is becoming the pattern for non-human callers too. The candid note to close on: misconfiguration, not the math, stays the most common failure mode.
The standards behind this page.
- Hardt, Ed. (2012). The OAuth 2.0 Authorization Framework. IETF RFC 6749.
- Sakimura, Bradley, Jones, de Medeiros, Mortimore (2023). OpenID Connect Core 1.0 (final, errata set 2). OpenID Foundation.
- Lodderstedt, Bradley, Labunets, Fett (2025). Best Current Practice for OAuth 2.0 Security. IETF RFC 9700 / BCP 240.
- OASIS (2005). Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS Standard. (standard set)
- Neuman, Yu, Hartman, Raeburn (2005). The Kerberos Network Authentication Service (V5). IETF RFC 4120.
- NIST (2025). Digital Identity Guidelines. NIST Special Publication 800-63-4 (supersedes 800-63-3).
Keep reading.
Sibling explainers in the Research section.
Talk. Done.
You talk, and clean, complete notes are waiting. See a co-pilot work on a real call.
No app required. Just your phone number.