Security Patterns and Authentication Basics
How systems decide who you are and what you may do: sessions vs tokens, OAuth 2.0 and OpenID Connect at a high level, JWTs, and the federated identity, gatekeeper and valet key patterns.
In a nutshell
- Authentication proves who you are; authorisation decides what you may do. Keep them separate.
- OAuth 2.0 lets an app act on a user's behalf with a scoped access token; OpenID Connect adds login on top.
- Federated identity: let a dedicated identity provider handle logins instead of every app storing passwords.
- Gatekeeper puts a hardened checkpoint in front of services; valet key grants narrow, temporary access to resources.
Sessions vs tokens
After login, a server either stores a session and gives the browser a random ID in a cookie, or hands the client a signed token (often a JWT) that carries the user ID and expiry. The trade-offs are covered in the Stateless services topic: sessions are easy to revoke, tokens avoid a lookup and work across services but are hard to revoke before they expire.
OAuth 2.0 and OpenID Connect
OAuth 2.0 answers: "how can this app access my data at another service without my password?" The user signs in at the authorization server and approves specific scopes; the app receives an access token to call the resource server (the API). OpenID Connect builds on OAuth 2.0 and adds an ID token that tells the app who the user is, which is what "Sign in with Google" uses.
Authorization code flow (with PKCE)
All steps The user signs in at the authorization server, never in the app. The app exchanges a one-time code for tokens and calls the API with the access token.
- The user clicks "Sign in".
- The app redirects to the authorization server with the scopes it wants and a PKCE challenge.
- The user logs in there and approves the scopes; the app never sees the password.
- The authorization server redirects back with a short-lived one-time code.
- The app exchanges the code, proving with the PKCE verifier that it started the flow.
- It receives an access token (and, with OpenID Connect, an ID token saying who the user is).
- The app calls the API with the access token; the API checks its signature, expiry and scopes.
Diagram as text
- The user clicks "Sign in".
- The app redirects to the authorization server with the scopes it wants and a PKCE challenge.
- The user logs in there and approves the scopes; the app never sees the password.
- The authorization server redirects back with a short-lived one-time code.
- The app exchanges the code, proving with the PKCE verifier that it started the flow.
- It receives an access token (and, with OpenID Connect, an ID token saying who the user is).
- The app calls the API with the access token; the API checks its signature, expiry and scopes.
| Token | For | Lifetime |
|---|---|---|
| Access token | Calling APIs (checked by the resource server) | Short: minutes to an hour |
| Refresh token | Getting new access tokens without logging in again | Long; revocable; store carefully |
| ID token (OIDC) | Telling the app who logged in | Short; not for calling APIs |
Federated identity
Instead of each application keeping its own users and passwords, delegate authentication to an identity provider (Google, Microsoft Entra ID, Okta, Auth0, Keycloak). Users get single sign-on, password policies and multi-factor authentication live in one place, and applications receive standard tokens. Applications then do only authorisation: given this verified identity, is this action allowed?
Gatekeeper and valet key
Gatekeeper: a dedicated, hardened host (often the API gateway or a WAF) validates and sanitises every request before it reaches the services that hold data and secrets. If the gatekeeper is compromised, the attacker still does not have the keys to storage.
Valet key: instead of proxying file traffic or sharing storage credentials, give the client a short-lived token scoped to one resource and one action, such as a presigned upload URL (see Blob and object storage).
- Least privilege: every service and token gets only the permissions it needs.
- Defence in depth: TLS everywhere (including inside the network), validation at every layer, encrypted data at rest.
- Secrets in a secret manager, never in code or config files; rotate them.
- Audit logs of who did what, kept where attackers cannot edit them.
Common mistakes
- Confusing authentication with authorisation, checking only that a user is logged in.
- Using an ID token to call APIs, or accepting tokens without checking signature, issuer, audience and expiry.
- Long-lived access tokens with no revocation.
- Building your own login, password storage and MFA when an identity provider would do.
Interview questions
Try answering out loud before you open each one.
How do users authenticate across your web app, mobile app and services?
Delegate to an identity provider using OpenID Connect with the authorization code flow plus PKCE. Clients receive short-lived access tokens (JWTs) and refresh tokens. The API gateway validates tokens (signature, issuer, audience, expiry) and passes the user identity to services, which authorise each action by role or ownership. Refresh tokens are revocable for logout and compromised devices.
Check yourself
Related topics
Further reading
- RFC 6749: The OAuth 2.0 Authorization Framework IETF
- RFC 7636: Proof Key for Code Exchange (PKCE) IETF
- OpenID Connect OpenID Foundation
- Federated Identity pattern Microsoft Azure Architecture Center
Your notes
Saved in this browser as you type.
Finished this topic?
Mark it read to track your progress, then carry on with the next one.