OAuth2

Definition

OAuth2 (Open Authorization 2.0) is the global standard for delegated authorization: it lets a third-party application access protected resources on behalf of a user, without ever handling their password.

It is what sits behind the "Sign in with Google" button — and the protocol that every PSD2 API uses to materialise the PSU's consent and issue access tokens to the TPPs.

OAuth2 vs OpenID Connect vs OAuth1

• OAuth2 — authorization ("I authorise this app to read my accounts"), the base protocol.
• OpenID Connect (OIDC) — an authentication layer placed on top of OAuth2 ("this app knows it's really me"), used for consumer SSO.
• OAuth1 (2010) — an older, more complex standard, now all but abandoned.

In PSD2, it is OAuth2 everywhere, sometimes enriched with OIDC building blocks to authenticate the PSU.

The PSD2 flow: Authorization Code + PKCE

1. The TPP builds an authorization URL and redirects the PSU to the ASPSP's authentication page.
2. The PSU authenticates (login + SCA) and consents to the requested scope.
3. The ASPSP sends the PSU back to the TPP's callback with a single-use authorization code.
4. The TPP exchanges this code (server-side, via mTLS + QSealC) for an access token and a refresh token.
5. The TPP uses the access token (in Authorization: Bearer) on every call.

PKCE (Proof Key for Code Exchange) protects against code interception, and it is mandatory under PSD2.

The key concepts

• Resource Owner — the PSU (owner of the data).
• Client — the TPP (the application requesting access).
• Resource Server — the ASPSP's API (which hosts the data).
• Authorization Server — the ASPSP's server that authenticates and issues the tokens.
• Scope — the scope of the consent (accounts.read, payments.write).
• Access Token — a short-lived token (5 to 60 min) for calling the API.
• Refresh Token — a long-lived token (up to 180 days in AIS) to renew the access token without re-SCA.

What OAuth2 does not do

• Does not authenticate the user: that is OIDC or SCA on the bank's side.
• Does not sign the requests: that is the QSealC in PSD2.
• Does not secure the transport: that is mTLS with QWAC.
• Does not define the business scopes: each ASPSP and each standard (STET, Berlin Group) sets them.

PSD2 specifics

"Raw" OAuth2 is not enough; it is always complemented by:

• mTLS + QWAC at the transport layer;
• HTTP signature + QSealC at the application layer;
• mandatory PKCE on the Authorization Code Flow;
• SCA triggered by the ASPSP at consent (and every 180 days for AIS);
• a long-lived refresh token for AIS (up to 180 days since the 2022 RTS update).

In the PSD2 ecosystem

OAuth2 is PSD2's universal consent mechanism: without it, there would be no standardised way for a PSU to authorise a TPP to access their accounts without handing over their password.

Concrete examples

• Connecting an AISP: linking Bankin' or Pennylane to your bank is exactly the Authorization Code Flow + PKCE — the redirect window to your bank corresponds to steps 1 to 3.
• Long-lived refresh token: since 2022, an AISP keeps a refresh token for up to 180 days without re-SCA, which lets it refresh your accounts every day for 6 months.
• Common mistake: confusing code_verifier and code_challenge (the challenge = SHA256(verifier) sent at authorization, the verifier sent at the exchange) → invalid_grant.
• Libraries: openid-client (Node, PKCE + mTLS), Authlib (Python), Spring Security OAuth2 Client (Java) — preferable to a homemade implementation.
• Scopes: the names differ (aisp/pisp/cbpii vs accounts.read/payments.write) — read each ASPSP's spec.
• FIDA outlook: OAuth2 remains the pivotal consent protocol, enriched with a unified Permission Dashboard and extended scopes (insurance, credit, savings).