OAuth is an open authorization standard that lets one application access resources held by another on a user's behalf, using time-limited access tokens instead of the user's password. OAuth 2.0, defined in RFC 6749 (2012), underpins "Sign in with Google" buttons, most public APIs and open banking in the UK and EU. It handles delegated authorization, not identity, which OpenID Connect adds. In the common authorization code flow with PKCE, the user logs in at the authorization server, the app exchanges a one-time code for an access token, and tokens typically expire within 5 to 60 minutes. Under PSD2, AISPs and PISPs reach bank APIs through OAuth after strong customer authentication at the bank.
What is OAuth, and what it is not
OAuth handles delegated authorization: it tells an API what a client may do, such as "read transactions on this account for 180 days". It does not by itself tell the client who the user is. That job is done by OpenID Connect, a layer built on OAuth 2.0 that adds a signed ID token with identity claims. Many OAuth security incidents come from treating an access token as proof of login.
The standard defines four roles: the resource owner (the user), the client (the app), the authorization server that issues tokens, and the resource server (the API).
How does OAuth authentication work
The most common flow is the authorization code grant with PKCE:
- The app redirects the user to the authorization server with the scopes it wants.
- The user logs in there, never in the app, and approves the request.
- The server redirects back to the app's registered callback URL with a one-time code.
- The app exchanges the code, plus its client secret or a signed assertion, for an access token and often a refresh token.
- The app calls the API with the access token in the Authorization header.
Access tokens are kept short-lived, often 5 to 60 minutes, so a leaked one expires quickly. The current security best practice (RFC 9700) drops the implicit and password grants.
OAuth for API access between servers
When no user is involved, the client credentials grant lets a backend authenticate with its own ID and secret and receive a token scoped to specific operations. Compared with a static API key, this gives expiry, narrow scopes and central revocation.
OAuth in open banking
Under PSD2, account information service providers (AISPs) and payment initiation service providers (PISPs) reach bank APIs through OAuth 2.0 flows. The user is redirected to their bank, completes strong customer authentication there, and the bank issues a token tied to a specific consent. The UK Open Banking standard and many EU banks use the FAPI security profile, adding mutual TLS with eIDAS certificates so the bank knows which licensed provider holds the token. In the EU, the period after which an AISP must send the user back for reauthentication was extended from 90 to 180 days in 2023.
Common failure points
Weak redirect URI validation, tokens stored in browser local storage, overly broad scopes and refresh tokens that never expire cause most real breaches. For a buyer reviewing an AISP or PISP, token handling and consent records are part of the technical due diligence.