Engineer's toolkit
Authentication and authorization
Authentication proves who you are, authorization decides what you can do, and service-to-service calls need their own identity. The map for the rest of this topic.
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
| Step | Concept | What it answers |
|---|---|---|
| 1 | Sessions and cookies | How does a browser stay logged in safely? |
| 2 | JWTs and token validation | How do I verify a signed token without calling the issuer? |
| 3 | OAuth and OpenID Connect | How do I let a third-party app act for a user, or sign users in? |
| 4 | Authorization models and IDOR | Which model fits, and where do ownership checks go? |
| 5 | MFA and passkeys | What 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.
Related
Sessions and cookies
How a browser login stays alive. Cookie attributes that matter, session fixation, CSRF, and why server-side sessions are easier to revoke than signed tokens.
OAuth and OpenID Connect
OAuth 2.0 delegates access to a third-party app. OpenID Connect adds a login identity on top. The authorization code flow with PKCE is the safe default.
Authorization models and IDOR
Compare RBAC, ABAC and relationship-based access, and learn how insecure direct object references let users read each other's data.
IAM and least privilege
How cloud identity works, why least privilege is a habit rather than a checkbox, and where the org-level guardrails sit. Start here for the map of IAM pages.