Authentification et jeton d'accès OAuth2

➤ Schéma du principe de récupération du jeton d'accès OAUTH2

En tant que développeur d'une application désirant utiliser cette API, l’obtention d'un jeton d’accès OAUTH2 vous est nécessaire et se fait grâce au processus suivant :

Références



Développement pas à pas

1. Le client vous indique l'identité de sa banque teneur de compte.

 

2. Vous initiez la séquence de récupération du jeton d'accès OAUTH2 en redirigeant le client via son navigateur internet vers l'infrastructure informatique d'autorisation de la banque teneur de compte, le détail des liens et des paramètres se trouvent ci-après :

book picto Voir aussi [STET Framework page 21]

GET /authorize?response_type=code&client_id={clientId}&redirect_uri={redirectUri}&scope={scope}[&state={state}]

Nom   Description Type
response_type [1..1] Type de jeton attendu Chaîne [10] => doit être renseignée avec le "code"
client_id [1..1] Votre identification en tant que TPP

Chaîne[34] =>

Si l’enregistrement du TPP a été réalisé au travers du processus de "GO Live" via notre portail 89C3 API (ancienne procédure)

  • Doit être égale à la partie "OrganizationIdentifier" du "Distinguished Name" du certificat eiDAS, en accord avec la spécification ETSI
  • Numéro d’agrément donné par votre autorité compétente (PSDXX-YYYYYYYY-ZZZZZZZZ)

Ou si l’enregistrement du TPP a été réalisé via l’API register (procédure actuelle)

  • Doit être égale au client_id retourné dans la réponse au POST /register
redirect_uri

[0..1]

[1..1]

URL de re-routage vers votre application Chaîne [140] => champ obligatoire pour les Banques Populaires, la Banque Palatine et la Banque de Savoie
scope [0..1]

Spécifie les accréditations génériques sur lesquelles notre client et vous, vous vous êtes accordés :

Pour un AISP :

  • aisp
  • extended_transaction_history => ce scope n'est pas autorisé pour les Banques Populaires, la Banque Palatine et la Banque de Savoie

Pour un CBPII :

  • piisp
Chaîne [140] => les espaces délimitent la liste des rôles
state [0..1]

Etat interne qui peut être utilisé par vous pour gérer le contexte

Chaîne [34]



3. La banque teneur de compte (ASPSP) va :

  • Identifier et authentifier le client par l'une des méthodes d'authentification forte qu'elle propose et présente au client;

  • Effectuer des vérifications liées à votre profil en tant qu'AISP ou CBPII (validité des certificats QWAC et QSealc et de votre rôle dans le référentiel de place, non révocation de votre profil, etc.).

 

4. Une fois ces vérifications effectuées et si elles sont concluantes, la banque va vous rediriger notre client vers votre site en utilisant l'URL de "call-back" et les paramètres ci-après. A noter que vous devrez nous communiquer cette URL lors de votre enregistrement en tant que TPP consommateur de nos API,

  • soit lors du processus de "GO Live" via notre portail 89c3 API (ancienne procédure) ;
  • soit via l’API register (procédure actuelle).

book picto Voir aussi [STET Framework page 22]

Nom   Description Type
code [1..1] Code court utilisé pour récupérer le jeton d'accès Chaîne [34]
state [0..1] Etat interne si fourni par vous Chaîne [34]

 

5. Vous allez pouvoir alors demander directement à la banque le jeton d'accès OAUTH2 via un appel de type POST envoyé avec les paramètres suivants : 

book picto Voir aussi [STET Framework page 22]

Nom Description Type
grant_type [1..1] Type d'autorisation requise Chaîne [34] => doit être renseignée avec le "authorization code"
code [1..1] Code court fourni précédemment par l' ASPSP Chaîne [34]
redirect_uri [1..1] URL de re-routage du TPP Chaîne [140] => doit être égale au redirect_uri fournie dans la requête GET /token.
client_id [1..1] Identification du TPP

Chaîne[34] =>

Si l’enregistrement du TPP a été réalisé au travers du processus de "GO Live" via notre portail 89C3 API (ancienne procédure)

  • Doit être égale à la partie "OrganizationIdentifier" du "Distinguished Name" du certificat eiDAS, en accord avec la spécification ETSI
  • Numéro d’agrément donné par votre autorité compétente (PSDXX-YYYYYYYY-ZZZZZZZZ)

Ou si l’enregistrement du TPP a été réalisé via l’API register (procédure actuelle)

  • Doit être égale au client_id retourné dans la réponse au POST /register

Exemple

POST /token HTTP/1.1      Host: server.example.com      Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW      Content-Type: application/x-www-form-urlencoded      grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA      &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb      &client_id={clientId}

 

6. La banque teneur de compte (ASPSP) va :

  • Effectuer des vérifications liées à votre profil en tant qu'AISP ou CBPII (validité des certificats QWAC et QSealc et de votre rôle, non révocation de votre profil etc. 

  • Vous identifier et vous authentifier en tant qu'AISP ou CBPII via votre certificat que vous mettrez à disposition pour sécuriser l'échange mutuel

 

7. Une fois ces vérifications effectuées et si elles sont concluantes, la banque va vous renvoyer une réponse HTTP200 (OK) qui contiendra les données suivantes :

book picto Voir aussi [STET Framework page 23] 

Nom Description Type
access_token [1..1] Jeton d'accès fourni par l'ASPSP au TPP Chaîne [140]
token_type [1..1] Type du jeton d'accès fourni ("Bearer" or "MAC") Chaîne [10] => doit être renseignée avec "Bearer"
expires_in [0..1] Durée de vie du jeton, en secondes. Le jeton peut être utilisé plusieurs fois tant qu'il n'a pas expiré.

Numérique

refresh_token [0..1]

Jeton de rafraîchissement qui peut être utilisé dans le cas d'une future requête de renouvellement de jeton.

Chaîne [140]

 

Exemple

HTTP/1.1 200 OK      Content-Type: application/json;charset=UTF-8      Cache-Control: no-store      Pragma: no-cache      {        "access_token":"2YotnFZFEjr1zCsicMWpAA",        "token_type":"example",        "expires_in":3600,        "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"      } 

 

8. Dès que le jeton d'accès OAUTH2 délivré par la banque (valable 90 jours) a été récupéré par vos soins, vous pourrez le présenter pour pouvoir consommer l'API (voir les cas d'usage pour les méthodes de l'API).



➤ Authentification du client

Méthodes d'identification du client

Il existe trois méthodes différentes pour l'identification du client qui se doit d'être pertinente pour l'ASPSP (établissement de crédit teneur de compte).

Celles-ci sont implémentées de différentes manières :

  • soit durant le processus d'authentification (cf. § 3.4), pour la plupart des cas d'utilisation concernant les AISP et les CBPII;
  • soit durant le consentement, par exemple dans le cas d'une requête de paiement (cf. § 3.5)

 

Principe pour la méthode REDIRECT > cette méthode s'applique pour les Banques Populaires, la Banque Palatine et la Banque de Savoie

Dans le cas de cette méthode, l'identification du client est faite entièrement par l'ASPSP.

L'AISP va orienter le client vers le service d'authentification de l'ASPSP, ce qui veut dire que le client va délaisser temporairement l'interface de l'AISP pour s'identifier via l'interface de l'ASPSP.

Si l'AISP a déjà récupéré un identifiant du client qui peut être approuvé par l'ASPSP de manière sûre alors dans ce cas l'identifiant peut être inclus dans la redirection à condition que le protocole de redirection le permette.

Une fois l'identification achevée, l'ASPSP va rediriger le client vers l'interface de l'AISP.

 

Exceptions à l'authentification forte

Les exceptions à une authentification forte sont prévues par les normes techniques de réglementation (éditées par l'Agence Bancaire Européenne) portant sur l'authentification forte et tout particulièrement sur l'initiation des services de paiement.

Dans ce cas, l'API offre la possibilité au TPP de fournir toute information utile à l'ASPSP.

Au final, c'est l'ASPSP qui est garant de la décision d'appliquer ou non cette exception.