Guide

Every request answers two questions. Authentication (authn) asks who is calling. Authorization (authz) asks whether that caller may do this thing to this object. Teams usually fix the first question quickly and get the second wrong. Most real breaches are failures of authorization after a valid login.

The flow in one picture

Authentication happens once per session. Authorization happens on every request, for every object.

Concepts in this topic

StepConceptWhat it answers
1Sessions and cookiesHow does a browser stay logged in safely?
2JWTs and token validationHow do I verify a signed token without calling the issuer?
3OAuth and OpenID ConnectHow do I let a third-party app act for a user, or sign users in?
4Authorization models and IDORWhich model fits, and where do ownership checks go?
5MFA and passkeysWhat second factor resists phishing?

Password storage is covered in password hashing. Its primitives are in crypto basics.

Service-to-service identity

Authentication isn't only for people. When one service calls another, it still needs an identity. Shared static API keys in config files are the common shortcut, and they leak. Prefer short-lived credentials issued per workload, such as cloud IAM roles or mutual TLS with a certificate from an internal authority. Each call then carries a verifiable identity, and rotation happens automatically. The cloud-side setup is in IAM and access.

Decisions to make early

Five decisions shape most auth designs. They're cheaper to make before launch than to unwind after:

  • Where state lives. Server-side sessions can be revoked at once. Stateless tokens can't, until they expire.
  • Who issues identity. Building your own login is rarely worth it. Most teams should delegate to an identity provider through OIDC.
  • Where rules live. Keep the authorization policy in one layer, so the API, background jobs and admin tools agree.
  • How recovery works. Account recovery is a login path, so it needs the same checks as login.
  • How services prove themselves. Pick short-lived workload identities before you have static keys to remove.

Common mistakes

  • Treating a successful login as permission to read every object.
  • Storing long-lived secrets for service calls in code or environment files.
  • Assuming the UI hides what the API should block.
  • Using a JWT where a revocable session would be simpler.

Key takeaways

  • Authentication proves identity once per session. Authorization checks each object on each request.
  • Use sessions for browser apps and tokens for multi-service APIs, and make sure both can be revoked.
  • Delegate with OAuth code flow and PKCE, and use OIDC for login identity.
  • Give services short-lived workload identities, not shared static keys.

Further learning

Pick one concept page from the table and read it end to end before the next. Authorization is the place where most bugs live, so start there if you're short on time.