Application identity: OAuth, OIDC, and tokens

A logged-in browser and an authorized API request are separate steps

Cloud IAM controls access to cloud resources. Application authentication establishes who a caller is. Application authorization decides what that caller may do, including which account or record they may access. Those decisions cannot be inferred solely from the frontend displaying a user's name.

OAuth 2.0 defines delegated authorization flows. OpenID Connect adds an identity layer for login. A JWT is a token format containing encoded claims and, in its signed form, a signature. Reading its payload is not the same as verifying that signature or trusting the issuer. Access tokens are not necessarily JWTs.

An ID token tells its intended client about authentication. An access token is presented to the resource server under that API's configured contract. Treating an ID token as a universal API credential confuses these audiences.

Trace a proposed request

Imagine a browser user signs in through an identity provider, then asks Accounts for account A. In a normal supported browser flow, the client uses the provider's SDK and appropriate authorization-code/PKCE handling. The API then validates the access token according to its contract before checking whether that user may access account A.

The layers answer different questions:

A valid signature does not skip the last two rows. A role used by CI to access AWS is also not a human application session; both may involve OIDC while trusting different issuers, subjects, and audiences.

Inspect the actual MicroBank gap

The pinned frontend uses Auth0, while the API baseline lacks server-side token validation. Its existing browser login therefore does not establish account-level protection in the backend. Keep the current local exercises private and synthetic until authentication and authorization are deliberately implemented and tested. A separate demo-login branch is a UI convenience, not proof of security.

A provider such as Auth0, Okta, or Microsoft Entra ID can support login. Provider choice does not decide how a MicroBank user maps to an account or which user may withdraw from it. Those are application design and test responsibilities.

Practice with a decision table, not a real token

Draw browser → identity provider → frontend → Accounts API → account database. Mark where the token is issued, its intended audience, and where it is validated. Fill in these expected outcomes:

• No token, when the endpoint requires authentication: reject the request according to the API's authentication policy.
• Invalid signature, wrong issuer/audience, or expired token: reject before accessing account data.
• Valid token for user A requesting A's permitted account: continue to application rules.
• Valid token for user A requesting B's account: deny access unless a deliberate permission authorizes it.

These are intended tests, not claims that the baseline passes. For JWT access tokens, use the provider's maintained validation library with the required issuer, audience, algorithms, and time checks. Do not hand-write signature verification or paste real bearer tokens into public decoders. Tokens belong neither in URLs nor ordinary application logs.

Checkpoint and next step

Why can a correctly signed token still be rejected? It may be expired, intended for another API, issued under an untrusted configuration, or lack the required authorization. Why is hiding a button insufficient? A caller can send requests directly to the API.

Carry the explicit authentication gap into the cloud design lab. The local MicroBank guide preserves real Auth0 behavior while documenting backend work still needed; it does not invent an authentication implementation.

References: OpenID Connect Core↗, OAuth security guidance↗, JWT best practices↗, and Auth0 access-token validation↗.