Authentication Method Lab

Third-party developers (server-side)

You publish a public REST API of non-sensitive reference data (maps, weather, exchange rates). Thousands of developers call it from their own backends. You need to meter usage per plan and cut off abusers.

• ▸Public, low-sensitivity data — no per-user records
• ▸Must identify the calling project for quotas, billing and analytics
• ▸Issued/revoked self-service from a developer dashboard

Employees in the browser

Your company runs a modern suite of internal web apps. You operate your own identity provider. Employees should log in once and move between apps without re-authenticating.

• ▸You need to authenticate the user (who they are)
• ▸Single sign-on across several first-party web apps
• ▸Modern greenfield stack; some apps will get mobile clients later

Backend service → backend service

Two microservices you own call each other inside a zero-trust network where you assume the network itself is hostile. Each service must cryptographically prove its identity to the other.

• ▸Machine-to-machine, no user involved
• ▸Zero-trust: mutual authentication, not just a shared secret
• ▸You control both ends and can run an internal CA / service mesh

Your server → customers' receiving endpoints

You POST event notifications (payment succeeded, build finished) to URLs your customers register. Each customer must be able to verify a delivery genuinely came from you and was not tampered with or replayed.

• ▸You are the sender; thousands of independent receivers
• ▸Receivers must verify authenticity AND payload integrity
• ▸Must survive a malicious proxy altering the body

Users in the browser, one app

A classic server-rendered web application with its own login form. Pages are rendered by one backend and served to the user's browser. No third parties, no SPA, no mobile.

• ▸First-party browser app; server renders every page
• ▸Users log in with their own account to this one app
• ▸No cross-app SSO required, no API clients

Enterprise employees in the browser

You sell a browser-only web application to large enterprises. Each customer wants employees to sign in through their existing corporate IdP (ADFS / Okta). Their IdP and the rest of their SaaS catalog are standardised on one federation protocol.

• ▸Browser-only app — no mobile, no public API surface
• ▸Must consume the customer's existing enterprise IdP
• ▸That IdP and their other SaaS all speak SAML 2.0

External apps accessing your users' data

Independent developers build apps that act on behalf of your users — "export my reports to app X". A user should grant app X scoped access to their data without ever handing over their password, and be able to revoke it.

• ▸A third party accesses one user's resources with that user's consent
• ▸Access must be scoped (read reports only) and revocable
• ▸The user must never share their password with the third party

Many API nodes validating a user token

Your API runs as many stateless replicas behind a load balancer and must validate the caller's access token on every request without a round-trip to a central session store or auth server.

• ▸Horizontally scaled, stateless nodes — no sticky sessions
• ▸Each node must validate the token locally, offline
• ▸Token carries the user id, scopes and an expiry

A service (no user) → another service

A nightly batch service needs to call an internal API. There is no user in the loop. You have no shared PKI or service mesh, but you do run an OAuth 2.0 authorization server. You want short-lived, scoped, revocable credentials — not a static secret living forever in config.

• ▸Machine client, no user; no mutual-TLS / PKI available
• ▸You already operate an OAuth 2.0 authorization server
• ▸Want expiring, scoped, centrally-revocable credentials

Mobile app → your API, per request

Your mobile app has already logged the user in via OIDC and holds a short-lived access token. The question is narrowly how the app should present that token to your API on each request.

• ▸The token already exists (issued by the OIDC flow)
• ▸Question is only the transport on each API call
• ▸Standard, cache-friendly, framework-supported

A few admins in the browser

A read-only internal status dashboard, reachable only over the corporate VPN, used by a handful of ops staff. There is no identity provider and no application framework — it is a single static-ish page behind a reverse proxy. You need the simplest standards-based per-person gate.

• ▸Internal-only, VPN-gated, very low exposure
• ▸No IdP, no session framework, no login UI to build
• ▸Must be a standard the reverse proxy already supports