OAuth2

Definición

OAuth2 (Open Authorization 2.0) es el estándar mundial de la autorización delegada: permite a una aplicación de terceros acceder a recursos protegidos en nombre de un usuario, sin manipular su contraseña.

Es lo que se esconde tras el botón «Iniciar sesión con Google» — y el protocolo que usan todas las API DSP2 para materializar el consentimiento del PSU y emitir los tokens de acceso a los TPP.

OAuth2 vs OpenID Connect vs OAuth1

• OAuth2 — autorización («autorizo a esta app a leer mis cuentas»), el protocolo de base.
• OpenID Connect (OIDC) — capa de autenticación montada sobre OAuth2 («esta app sabe que soy yo de verdad»), utilizada para el SSO de gran público.
• OAuth1 (2010) — estándar antiguo, más complejo, prácticamente abandonado.

En la DSP2, es OAuth2 en todas partes, a veces enriquecido con bloques OIDC para autenticar al PSU.

El flujo DSP2: Authorization Code + PKCE

1. El TPP construye una URL de autorización y redirige al PSU a la página de autenticación del ASPSP.
2. El PSU se autentica (login + SCA) y consiente el perímetro solicitado.
3. El ASPSP devuelve al PSU al callback del TPP con un código de autorización de un solo uso.
4. El TPP intercambia ese código (del lado del servidor, vía mTLS + QSealC) por un access token y un refresh token.
5. El TPP usa el access token (en Authorization: Bearer) en cada llamada.

El PKCE (Proof Key for Code Exchange) protege contra la interceptación del código y es obligatorio en la DSP2.

Los conceptos clave

• Resource Owner — el PSU (propietario del dato).
• Client — el TPP (la aplicación que solicita el acceso).
• Resource Server — la API del ASPSP (que aloja el dato).
• Authorization Server — el servidor del ASPSP que autentica y emite los tokens.
• Scope — el perímetro del consentimiento (accounts.read, payments.write).
• Access Token — token corto (de 5 a 60 min) para llamar a la API.
• Refresh Token — token largo (hasta 180 días en AIS) para renovar el access token sin volver a hacer SCA.

Lo que OAuth2 no hace

• No autentica al usuario: eso es OIDC o la SCA del lado del banco.
• No firma las peticiones: eso es el QSealC en la DSP2.
• No asegura el transporte: eso es el mTLS con QWAC.
• No define los scopes de negocio: cada ASPSP y cada estándar (STET, Berlin Group) los fija.

Especificidades DSP2

OAuth2 «en crudo» no basta; siempre se completa con:

• mTLS + QWAC a nivel de transporte;
• HTTP-signature + QSealC a nivel de aplicación;
• PKCE obligatorio en el Authorization Code Flow;
• SCA disparada por el ASPSP en el consentimiento (y cada 180 días para el AIS);
• refresh token largo para el AIS (hasta 180 días desde la evolución de los RTS en 2022).

En el ecosistema PSD2

OAuth2 es el mecanismo de consentimiento universal de la DSP2: sin él, no habría ninguna forma estandarizada de que un PSU autorice a un TPP a acceder a sus cuentas sin entregar su contraseña.

Ejemplos concretos

• Conexión de un AISP: vincular Bankin' o Pennylane a tu banco es exactamente el Authorization Code Flow + PKCE — la ventana de redirección hacia tu banco corresponde a los pasos 1 a 3.
• Refresh token largo: desde 2022, un AISP conserva un refresh token hasta 180 días sin volver a hacer SCA, lo que permite refrescar tus cuentas cada día durante 6 meses.
• Error frecuente: confundir code_verifier y code_challenge (el challenge = SHA256(verifier) enviado en la autorización, el verifier enviado en el intercambio) → invalid_grant.
• Bibliotecas: openid-client (Node, PKCE + mTLS), Authlib (Python), Spring Security OAuth2 Client (Java) — preferibles a una implementación propia.
• Scopes: los nombres difieren (aisp/pisp/cbpii vs accounts.read/payments.write) — hay que leer la especificación de cada ASPSP.
• Evolución FIDA: OAuth2 sigue siendo el protocolo pivote del consentimiento, enriquecido con un Permission Dashboard unificado y scopes ampliados (seguros, crédito, ahorro).