OAuth 2.0 & OpenID Connect
One-line relationship: OAuth 2.0 answers what can this app do on my behalf; OIDC, a layer on top, answers who is this user. Everything else in this portal — FAPI 2.0, PKCE, DPoP, PAR — is a hardening of this one substrate.
What it is
OAuth 2.0 is a delegated-authorization framework: it lets a client application get a scoped, time-limited credential (an access token) to call an API on a user’s behalf, without the app ever seeing the user’s actual password. Three roles, one exchange:
- Authorization Server (AS) — runs login and consent, issues tokens.
- Resource Server (RS) — the API that accepts the token and serves data.
- Client — the app requesting access; either confidential (can hold a secret — a server) or public (can’t — a browser SPA or mobile app). That distinction drives most of the security profile downstream: a public client can’t authenticate itself with a shared secret, so it needs PKCE, and can’t safely hold long-lived tokens without a backend, hence the BFF pattern.
OpenID Connect adds an identity layer: alongside the access token, the AS also issues an ID token — a signed JWT asserting who just authenticated (subject, issuer, audience, auth time). OAuth alone never tells the app who the user is; that’s OIDC’s entire job.
The only flow that matters here
FAPI 2.0 (and this portal) only ever uses the Authorization Code flow: the user authenticates at the AS, the browser gets redirected back with a short-lived authorization code, and the client exchanges that code — server-side, authenticated — for tokens at the AS’s token endpoint. Two older flows are explicitly excluded because they leak tokens into the browser: Implicit (tokens issued straight into the redirect URL) and Resource Owner Password Credentials (the app sees the user’s password directly). If you see either in a spec review, that’s a finding.
The vocabulary this portal assumes
| Term | What it is |
|---|---|
| Access token | The credential presented to the RS. Opaque or a JWT; short-lived. |
| Refresh token | Longer-lived credential used to mint new access tokens without re-authenticating the user. |
| ID token | Signed JWT from OIDC asserting identity — not used to call APIs. |
| Scopes | What access is being granted (accounts, payments). |
| Claims | Facts about the user or session carried in a JWT (sub, iss, exp, cnf). |
| JWK / JWKS | The public-key format, and the endpoint (/.well-known/jwks.json) an AS publishes them at so clients can verify token signatures. |
What to take to the client
OAuth/OIDC is the plumbing every other concept in this portal hardens. When something looks broken in a banking flow, the first question is always “which of these three roles is doing the wrong thing” — a client leaking a code, an AS accepting a forged redirect, an RS trusting an unverified token. Naming the role clarifies the fix.