OAuth2

Définition

OAuth2 (Open Authorization 2.0) est le standard mondial de l'autorisation déléguée : il permet à une application tierce d'accéder à des ressources protégées au nom d'un utilisateur, sans manipuler son mot de passe.

C'est ce qui se cache derrière le bouton « Se connecter avec Google » — et le protocole qu'utilisent toutes les API DSP2 pour matérialiser le consentement du PSU et délivrer les jetons d'accès aux TPP.

OAuth2 vs OpenID Connect vs OAuth1

• OAuth2 — autorisation (« j'autorise cette appli à lire mes comptes »), le protocole de base.
• OpenID Connect (OIDC) — couche d'authentification posée sur OAuth2 (« cette appli sait que c'est bien moi »), utilisée pour le SSO grand public.
• OAuth1 (2010) — ancien standard, plus complexe, quasiment abandonné.

En DSP2, c'est OAuth2 partout, parfois enrichi de blocs OIDC pour authentifier le PSU.

Le flux DSP2 : Authorization Code + PKCE

1. Le TPP construit une URL d'autorisation et redirige le PSU vers la page d'authentification de l'ASPSP.
2. Le PSU s'authentifie (login + SCA) et consent au périmètre demandé.
3. L'ASPSP renvoie le PSU vers le callback du TPP avec un code d'autorisation à usage unique.
4. Le TPP échange ce code (côté serveur, via mTLS + QSealC) contre un access token et un refresh token.
5. Le TPP utilise l'access token (en Authorization: Bearer) à chaque appel.

Le PKCE (Proof Key for Code Exchange) protège contre l'interception du code, et il est obligatoire en DSP2.

Les concepts clés

• Resource Owner — le PSU (propriétaire de la donnée).
• Client — le TPP (l'application qui demande l'accès).
• Resource Server — l'API de l'ASPSP (qui héberge la donnée).
• Authorization Server — le serveur de l'ASPSP qui authentifie et délivre les tokens.
• Scope — le périmètre du consentement (accounts.read, payments.write).
• Access Token — jeton court (5 à 60 min) pour appeler l'API.
• Refresh Token — jeton long (jusqu'à 180 jours en AIS) pour renouveler l'access token sans re-SCA.

Ce qu'OAuth2 ne fait pas

• N'authentifie pas l'utilisateur : c'est OIDC ou la SCA côté banque.
• Ne signe pas les requêtes : c'est le QSealC en DSP2.
• Ne sécurise pas le transport : c'est le mTLS avec QWAC.
• Ne définit pas les scopes métier : chaque ASPSP et chaque standard (STET, Berlin Group) les fixe.

Spécificités DSP2

OAuth2 « brut » ne suffit pas ; il est toujours complété par :

• mTLS + QWAC au niveau transport ;
• HTTP-signature + QSealC au niveau applicatif ;
• PKCE obligatoire sur l'Authorization Code Flow ;
• SCA déclenchée par l'ASPSP au consentement (et tous les 180 jours pour l'AIS) ;
• refresh token long pour l'AIS (jusqu'à 180 jours depuis l'évolution des RTS en 2022).

Dans l'écosystème PSD2

OAuth2 est la mécanique de consentement universelle de la DSP2 : sans lui, aucun moyen standardisé pour qu'un PSU autorise un TPP à accéder à ses comptes sans livrer son mot de passe.

Exemples concrets

• Connexion d'un AISP : relier Bankin' ou Pennylane à votre banque, c'est exactement l'Authorization Code Flow + PKCE — la fenêtre de redirection vers votre banque correspond aux étapes 1 à 3.
• Refresh token long : depuis 2022, un AISP conserve un refresh token jusqu'à 180 jours sans re-SCA, ce qui permet de rafraîchir vos comptes chaque jour pendant 6 mois.
• Erreur fréquente : confondre code_verifier et code_challenge (challenge = SHA256(verifier) envoyé à l'autorisation, verifier envoyé à l'échange) → invalid_grant.
• Bibliothèques : openid-client (Node, PKCE + mTLS), Authlib (Python), Spring Security OAuth2 Client (Java) — à préférer à une implémentation maison.
• Scopes : les noms diffèrent (aisp/pisp/cbpii vs accounts.read/payments.write) — lire la spec de chaque ASPSP.
• Évolution FIDA : OAuth2 reste le protocole pivot du consentement, enrichi d'un Permission Dashboard unifié et de scopes étendus (assurance, crédit, épargne).