L'accès aux API "information sur compte" ou "disponibilité des fonds" est autorisé via un jeton d'accès (access_token) qui peut être obtenu en appliquant le standard OAUTH2.

➤ Cinématique de récupération du jeton d'autorisation

1. Notre client (PSU) indique au TPP l'identité de son établissement teneur de compte.

2. Le TPP initie la séquence de récupération du jeton d'accès OAuth2 en redirigeant le client (PSU), via son navigateur internet, vers l'infrastructure informatique d'autorisation de l'établissement teneur de compte (ASPSP) et en utilisant la commande : GET /authorize

 Voir aussi la spécification de place STET 

3. Le teneur de compte (ASPSP) va :

• Identifier et authentifier son client via l'une des méthodes d'authentification forte dont il a été équipé 

• Effectuer des vérifications liées au TPP 

4. Une fois ces vérifications effectuées, et si elles sont concluantes, l’établissement bancaire va rediriger le client (PSU) vers le site du TPP en utilisant l'URL de "call-back" (redirection) transmise lors de l'enrôlement.

En effet, l'AISP doit préciser pour son APP consommatrice, une URL qui sera appelée par l'établissement bancaire :

• Si le PSU a autorisé la récupération de ses données par l'AISP

• Ou en cas de refus du consentement

• Ou si la cinématique d'identification et d'authentification est interrompue à l’une de ses étapes (exemple : timeout sur l'écran d'identification ou sur l'écran d'authentification forte).

Si le PSU a autorisé le TPP à récupérer ses données chez son teneur de compte, le TPP trouvera dans la réponse à cet appel un code à utilisation unique avec une durée de vie courte.

5. Via un appel de type POST /token, le TPP pourra alors demander directement au teneur de compte son jeton d'accès OAUTH2 (access_token) avec les éléments reçus précédemment dont le code à utilisation unique.

NB : les requêtes /token du flow Authorization Code doivent être envoyée SANS le paramètre « scope ».

 Voir aussi la spécification de place STET

6. L’établissement teneur de compte (ASPSP) va :

• Effectuer des vérifications liées à au profil du TPP en tant qu'AISP ou CBPII (validité des certificats et de l'agrément, non révocation, etc.)

• identifier et authentifier le TPP via le certificat QWAC envoyé pour sécuriser l'échange mutuel (validité des certificats, rôle, non révocation de votre profil, etc.)

7. Une fois ces vérifications effectuées et si elles sont concluantes, le teneur de compte va vous renvoyer une réponse HTTP 200 (OK) contenant, entres autres, le jeton d'accès OAUTH2 (access_token).

Voir aussi la spécification de place STET 1.4.0.47 / Part I / section 3.4.3.2 / page 23 

8. Dès que le jeton d'accès OAUTH2 (access_token) délivré par la banque a été récupéré par le TPP, il pourra le présenter pour pouvoir consommer les ressources de l'API.

Ce jeton est accompagné d’un refresh_token qui est à conserver. Lorsque l'access_token arrive à expiration, le TPP pourra en redemander un nouveau en suivant la rubrique "Vue d'ensemble" > "Rafraîchir votre jeton".

Au bout du délai réglementaire indiqué dans le jeton, le refresh_token arrive à expiration. Pour en récupérer un nouveau, le TPP devra reprendre cette cinématique "Récupérer votre jeton" et passer, de facto, par une nouvelle étape d’authentification forte du client auprès de son établissement bancaire (cf. point 3. ci-dessus). 

Pour plus de détails, voir aussi OAUTH 2.0 Authorization Framework : https://tools.ietf.org/html/rfc6749#section-4.1

➤ Exemple

Un exemple de requête est fourni dans la rubrique "Comment tester l'API ?" > "Assemblage sandbox".