Choose the Auth Pattern for 8 API Scenarios

Picking an authentication and authorization pattern is a judgment call: match the mechanism to who the caller is, how sensitive the data is, and what evidence you will owe an auditor. In this exercise you work through eight real scenarios. For each, choose the authentication mechanism and, where relevant, the authorization model — then, at the end, write the short justification a reviewer would expect for two of the trickier ones.

Refer back to the previous lesson as needed: API keys (machine clients, bearer), JWT (stateless user sessions), OAuth2/OIDC (delegated/scoped, third-party or first-party app→backend), mTLS (strong machine-to-machine), and RBAC/ABAC/ReBAC for authorization.

The 'just give the service account admin for now' decision

Scenario 1: A public weather API for developers

Quick check

You run a public weather API. Developers sign up, get a credential, and call it from their own servers. You need to identify each consumer and meter usage per plan. What fits best?

API keys — issued per developer/application, sent on each request, looked up to attribute and meter usage

mTLS — issue every hobbyist developer a client certificate

No auth — weather data is public anyway

OAuth2 authorization-code flow with user consent screens

Scenario 2: A single-page web app calling your own backend

Quick check

Your React SPA needs authenticated, stateless sessions against your own API, scaled across many backend instances with no shared session store. What fits best?

A static API key embedded in the JavaScript bundle

Short-lived JWT access tokens (via OIDC login) plus a refresh-token flow

mTLS from the browser

HTTP Basic auth with the password sent on every request

Scenario 3: Two internal microservices in a service mesh

Quick check

Two backend services inside your zero-trust mesh must authenticate to each other with no shared bearer secret that could leak. What fits best?

A shared API key both services hold in an env var

mTLS — each service presents its own certificate; the mesh verifies both sides

OAuth2 with a consent screen between the services

No auth — they are on the internal network

Scenario 4: Letting a third-party app post on a user's behalf

Quick check

A user wants to connect a third-party scheduling app so it can create calendar events in your product on their behalf — without giving the app their password, and limited to calendar writes only. What fits best?

Have the user paste their password into the third-party app

OAuth2 authorization-code flow with a scoped grant (e.g. calendar:write) and user consent

Give the third-party app your master API key

mTLS between your API and the third-party app

Scenario 5: An internal admin tool with three job functions

Quick check

An internal tool has three clear job functions — viewers (read dashboards), editors (change config), and admins (manage users). Access maps cleanly to job function. What authorization model fits best?

RBAC — viewer / editor / admin roles, each with a fixed permission set

ReBAC — model every user-to-resource relationship in a graph

No authorization — authentication is enough

Hardcode each user’s email in the code with an if-statement

Scenario 6: Per-region, business-hours, managed-device access

Quick check

An API must allow access only when the caller's region matches the resource's region, during business hours, and from a managed device. Roles alone can't express this. What fits best?

Invent a separate role for every region/hour/device combination

ABAC — a policy over user, resource, and context attributes (region, time, device posture)

Drop the conditions; they are too hard to implement

Client-side checks in the frontend that hide the button

Scenario 7: A document-collaboration product

Quick check

In your product, a user can access a document if they own it, or if it was shared with them directly, or if they belong to a team the document was shared with. Access follows ownership and sharing, not fixed roles. What fits best?

RBAC with one role per document

ReBAC — model owner/shared-with/team relationships and check the relationship on access

Give every authenticated user access to every document

A single “collaborator” role for everyone

Scenario 8: A bank-grade partner integration

Quick check

A financial partner integrates with your API to exchange transaction data. You need the strongest mutual machine authentication, with no shared bearer secret, plus scoped authorization on what the partner can read. What fits best?

mTLS for mutual authentication, combined with scoped authorization (OAuth2 scopes or ABAC policy) on the data

A single shared API key emailed to the partner

Username and password in the URL query string

No authorization once authenticated — partners are trusted

Write it up: justify two of your choices

Below, write the short justification a reviewer would expect for the two trickiest decisions: Scenario 2 (why JWT over an API key for the SPA) and Scenario 8 (why mTLS plus a scoping layer, not mTLS alone). Name the control each choice satisfies and the evidence you would show an auditor.

Exercise

~8 min

Justify your auth-pattern choices

SOC 2 CC6.1 (Logical Access) Finding

Justify the authentication and authorization choice for two API scenarios

ID:

API-AUTH-6.1.2

Criterion:

Auth mechanism matched to caller, sensitivity, and evidence obligation

Severity:

Design task

For the SPA (Scenario 2) and the bank-grade partner integration (Scenario 8), state the chosen authN mechanism and authZ model, the control each satisfies, and the evidence that proves it operates.

Auditor Notes

Scenario 2 (SPA->own backend): short-lived JWT via OIDC login + refresh tokens, NOT a bundled API key (a secret in client-side JS is public). Control: stateless authenticated sessions with bounded lifetime. Evidence: token policy (expiry, signing alg, key rotation), proof the verifier rejects alg:none/unsigned tokens, OIDC login logs. Scenario 8 (partner): mTLS for mutual machine authN (no shared bearer secret to leak) PLUS scoped authZ (OAuth2 scopes or ABAC) so the partner is least-privilege. Authentication is not authorization. Evidence: CA config + client-cert inventory with expiry + rotation/revocation (CRL/OCSP); the scope catalog or ABAC policy; access logs showing denied out-of-scope requests.

Write your remediation plan in YAML below. Fill in every field — replace all placeholder comments.

Loading editor…

What to carry forward

Authentication and authorization are two separate decisions, and the second is where most APIs break. Match the authentication mechanism to the caller (keys for machine consumers, JWT for your own app's users, OAuth2 for delegated third-party access, mTLS for high-assurance machine-to-machine) and the authorization model to how access actually works (RBAC for stable roles, ABAC for contextual rules, ReBAC for ownership/sharing graphs). Then, always, enforce authorization server-side, per request, against the specific object — and keep the evidence that proves it. The next module shows what happens when these controls are missing: the OWASP API Security Top 10.