Authentication, Sessions, and Tokens

Authentication establishes who or what is calling; it does not decide what that principal may do. Prefer a mature identity provider and standards-based validation over inventing login protocols. Whether using secure server sessions or short-lived tokens, validate issuer, audience, signature, time claims, lifecycle, and transport before constructing a trusted principal.

What will you be able to do?

• choose cookie sessions or bearer tokens based on clients and threats;
• validate identity tokens without trusting decoded claims blindly;
• store passwords with a modern adaptive hash when local passwords are unavoidable;
• design rotation, revocation, logout, and service identity.

Which browser pattern should you prefer?

For a same-origin browser application, an opaque server-side session in a Secure, HttpOnly, appropriately SameSite cookie often reduces token exposure to JavaScript. Add CSRF protection for state-changing requests. For distributed API clients, short-lived OAuth access tokens may be appropriate. Do not place tokens in URLs or browser local storage without a threat-informed reason.

What must token validation check?

1. Allowed algorithm and a trusted key selected by kid.
2. Cryptographic signature.
3. Exact issuer.
4. Expected audience.
5. Expiration and not-before with small documented clock skew.
6. Token type and required claims.
7. Revocation/session state where the risk requires it.

Decoding base64 is not validation. Cache provider keys with bounded TTL and handle key rotation. Never accept an algorithm supplied by the token as unrestricted policy.

Represent the result as an application-owned principal:

Tenant memberships and permissions come from your authoritative data, not arbitrary token roles unless governance explicitly makes the issuer authoritative for them.

What if the product stores passwords?

Use a maintained library implementing a current adaptive password hash such as Argon2id, unique salts, safe parameters, login throttling, breached-password policy, MFA options, secure reset tokens, and hash upgrades on successful login. Never encrypt passwords for later recovery.

Why does this matter in AI-native systems?

AI tools must execute as a constrained principal with delegated, auditable authority. A model cannot invent a user, tenant, or scope. Service-to-service calls should use workload identity and short-lived credentials where possible, not one shared API key copied across environments.

Common mistakes

• Confusing ID tokens with API access tokens.
• Logging tokens or returning them in error messages.
• Long-lived bearer tokens without rotation or revocation.
• Logout deletes a cookie but leaves server refresh/session authority active.
• Account enumeration through different login/reset responses.

AI Pair-Programmer Prompt

Exercise

Design authentication for a same-origin web app, CLI, and background worker. Include credential storage, validation, refresh, logout/revocation, CSRF, and audit events.

Acceptance criteria: stolen credentials have a bounded lifetime, each client uses an appropriate flow, and tests reject wrong issuer, audience, signature, expiry, and replay policy.

Knowledge check

1. Does decoding a JWT validate it?
2. What is the difference between authentication and authorization?
3. Why prefer short-lived workload identity?

---

Answers

1. No; signature and semantic claims must be verified against trusted policy.
2. Authentication establishes identity; authorization permits an action on a resource.
3. It reduces copied secrets and limits exposure duration.

Completion checklist

• Authentication uses a standard flow and maintained library.
• Token/session lifecycle is tested.
• No model input can establish authority.

Primary references

• OAuth 2.0 Security Best Current Practice
• OpenID Connect Core
• OWASP Authentication Cheat Sheet