Cloud Parts

Authentication

Proving who a user is, before anyone decides what they may do.

3 technologies on this page ↓
Live model
What you’re watchingMost requests carry a valid session cookie and go straight to the app. Requests without one are redirected to the identity provider; after the user signs in, the browser comes back with a code, the app swaps it for tokens and starts a session. The slow round trips are logins.

How it works

Authentication answers “who are you?”; authorization (see IAM) then answers “what may you do?”. A user proves identity with something they know (a password), something they have (a phone or security key) or something they are (a fingerprint), and multi-factor authentication (MFA) asks for two of them. A password is never stored as typed: the server keeps a salted, deliberately slow hash such as Argon2id or bcrypt, so a stolen database can’t simply be read back. After a successful login the app has to remember the user on every later request. It can hand the browser a random session ID in a cookie and keep the session on the server, which is easy to revoke, or it can issue a signed token such as a JSON Web Token (JWT) that any service can check without a lookup, which is hard to revoke before it expires. Most apps no longer check passwords themselves: they redirect the user to an identity provider (Google, Microsoft Entra ID or a customer’s own directory) using OpenID Connect or SAML, and get back a signed statement of who the user is. Passkeys go further and replace the password with a key pair: the private key never leaves the user’s device and only signs challenges for the site it was created for, which makes it resistant to phishing.

Think of it as

Checking in at a hotel. The front desk checks your passport once (authentication) and gives you a key card (the session). The card opens your room and the gym but not the kitchen (authorization), and it stops working when you check out.

Reach for it when

  • Any app where users have their own data, settings or permissions
  • Selling to companies whose IT team wants staff to sign in through their own directory (SAML or OIDC single sign-on) and be removed automatically when they leave (SCIM)
  • Protecting admin and high-value accounts with MFA or passkeys

Think twice when

  • Writing your own password storage, reset emails and MFA when a maintained library or provider does it; the details are easy to get wrong
  • Treating a valid login as permission: being signed in says who someone is, not what they may touch
  • Long-lived JWTs as sessions when you need instant logout or account suspension, unless you add a deny list

A real example

A project-management SaaS lets individuals sign up with email and a passkey, or with a password plus a code from an authenticator app. When a 2,000-person company buys it, their IT team connects the app to the company directory: employees click “Sign in with SSO”, the app redirects them to the company’s identity provider over SAML or OIDC, and the app never sees their passwords. SCIM pushes joiners and leavers, so an employee who leaves on Friday loses access when the directory disables them, not when someone remembers to delete the account.

Technologies

Specific products, and what each does differently.

Also used for authentication

Products of other kinds that are often used this way, grouped by what they are.

What each provider calls it

AWS
Amazon Cognito (user pools for sign-in, identity pools for AWS credentials); IAM Identity Center for staff SSO into AWS
Google Cloud
Identity Platform (Firebase Authentication plus SAML, OIDC and multi-tenancy); Firebase Authentication
Azure
Microsoft Entra ID for staff; Microsoft Entra External ID for customers (Azure AD B2C no longer sold to new customers since May 2025)
Open source & others
Keycloak (Apache 2.0, CNCF), Ory Kratos and Hydra (Apache 2.0), authentik (MIT core), Supabase Auth (MIT), Better Auth (MIT); hosted: Auth0, WorkOS

The standards you’ll meet#

They solve different problems and are often used together: a B2B app might take OIDC logins from individuals, SAML from enterprise customers, SCIM for provisioning and WebAuthn for passkeys.

StandardWhat it doesFormatTypical use
OAuth 2.0 (RFC 6749, 2012)Lets an app get limited access to an API on a user’s behalf. Authorization, not login.HTTP redirects; access tokens“Allow this app to read your calendar”
OpenID Connect (2014)An identity layer on top of OAuth 2.0: adds an ID token saying who signed inJSON; ID token is a JWT“Sign in with Google”, modern enterprise SSO
SAML 2.0 (2005)Single sign-on: the identity provider sends a signed assertion about the userXMLEnterprise SSO from a company directory
SCIM 2.0 (RFC 7643/7644, 2015)Creates, updates and deactivates accounts from a directoryJSON over RESTJoiners and leavers synced automatically
WebAuthn / FIDO2 (2019)Sign-in with a key pair held by the device, scoped to one siteBrowser API; public-key signaturesPasskeys and security keys
  • A JWT (RFC 7519) is just a signed, compact token format; OIDC uses it, but so do many home-grown session schemes.

In code · http

# 1. The app redirects the browser to the identity provider (OIDC authorization code flow with PKCE)
GET /authorize?response_type=code
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
    &scope=openid%20email
    &state=af0ifjsldkj
    &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
    &code_challenge_method=S256 HTTP/1.1
Host: login.example.com

# 2. After the user signs in, the provider sends the browser back with a one-time code
HTTP/1.1 302 Found
Location: https://app.example.com/callback?code=SplxlOBeZQQYbYS6WxSbIA&state=af0ifjsldkj

# 3. The app's server swaps the code for tokens, proving it started the flow
POST /token HTTP/1.1
Host: login.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
&client_id=s6BhdRkqt3&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

# 4. The id_token is a signed JWT saying who the user is; the app checks it and starts a session
HTTP/1.1 200 OK
Content-Type: application/json

{ "access_token": "SlAV32hkKG", "token_type": "Bearer", "expires_in": 3600,
  "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ..." }

Often confused with

Identity & access (IAM)Secrets managementRemote accessAPI gateways
Where it came from1979–2022

Passwords came with time-sharing. Robert Morris and Ken Thompson’s 1979 account of Unix password security recalls that the first Unix kept everyone’s actual passwords in a file that had to be guarded, and that on MIT’s CTSS an editing mix-up once printed the password file on every terminal at login. Unix moved to storing only an encrypted form, made it deliberately slow, and added a 12-bit random salt so that identical passwords looked different and precomputed attacks stopped working. bcrypt (Provos and Mazières, 1999) made the slowness adjustable as hardware got faster, and Argon2, winner of the 2013 to 2015 Password Hashing Competition, also made attackers pay in memory.

As people collected accounts on dozens of sites, the work moved to identity providers. SAML 2.0 (2005) let a company’s directory vouch for its staff at other organisations’ apps. OAuth 2.0 (2012) standardised how an app gets limited access to an API on a user’s behalf; it is an authorization protocol and says nothing about who the user is. OpenID Connect, ratified in February 2014, added a proper identity layer on top: an ID token, a signed JWT that says who signed in, to whom, and when.

Passwords and one-time codes can be typed into a fake site, so the industry moved to public-key credentials. The W3C published Web Authentication (WebAuthn) as a Recommendation in March 2019, and in May 2022 Apple, Google and Microsoft committed to passkeys that sync across a user’s devices. NIST’s 2025 guidelines now tell US federal systems to offer a phishing-resistant option, and to stop forcing periodic password changes and composition rules.

Why it’s built this way

Store a salted, slow hash, never the password
A password file will eventually leak. Morris and Thompson salted and slowed down Unix’s hashes so a stolen file would be expensive to crack; bcrypt and Argon2 let that cost grow with hardware.
Delegate login to an identity provider
With redirects (SAML, OIDC) the app never sees the user’s password, users keep one login, and an employer can switch off access centrally when someone leaves.
Build identity on OAuth 2.0 instead of a new protocol
Sites already used OAuth to call each other’s APIs. OpenID Connect reused that machinery for login, adding only a signed ID token, so libraries and providers could support both.
Key pairs bound to a site, not shared secrets
A password or SMS code can be typed into a fake site. A WebAuthn credential is scoped to the site that created it and only signs a challenge, so there is nothing reusable to steal.

Timeline

  1. 1979

    Morris and Thompson describe salted, slow password hashing in Unix

  2. 1999

    Provos and Mazières present bcrypt, with an adjustable cost

  3. 2005

    SAML 2.0 becomes an OASIS Standard

  4. 2012

    OAuth 2.0 published as RFC 6749

  5. 2014

    OpenID Connect ratified by the OpenID Foundation

  6. 2015

    Argon2 wins the Password Hashing Competition; JWT and SCIM 2.0 published as RFCs

  7. 2019

    WebAuthn becomes a W3C Recommendation

  8. 2022

    Apple, Google and Microsoft commit to passkeys

Sources24

Improve this page on GitHub