Activer la spécification Open Banking britannique

Guide de solutions techniques ForgeRock

Le secteur bancaire est en pleine mutation, les utilisateurs demandant un accès accru à leurs comptes et le partage des informations les concernant. Pour protéger les consommateurs, des réglementations ont vu le jour dans le but de poser un cadre concernant la création, la consultation et le partage des données financières.

Dans cet article technique, nous expliquons comment ForgeRock active la spécification Open Banking britannique via ForgeRock Identity Platform™ et la livraison de la banque de référence ainsi que du nouvel environnement sandbox de l'annuaire ForgeRock. Ce document se concentre principalement sur le profil de sécurité et l'annuaire ForgeRock Open Banking Directory.

Tout au long de ce document, nous avons fourni des liens vers la documentation de ForgeRock pour plus d'explications sur la fonctionnalité Open Banking dont il est question.

Trois exigences clés pour l'Open Banking

L'Open Banking fait référence au partage des données bancaires des utilisateurs via des API. Bien entendu, plus le nombre de tiers ayant accès à ces données est important, plus le risque est élevé.

Trois exigences clés s'appliquent à la sécurisation de toute architecture d'un écosystème Open Banking.

  1. Consentement : les banques ont besoin d'un moyen de confirmer qu'un utilisateur a accordé son consentement pour le partage de ses données, ce qui signifie qu'elles ont besoin de pouvoir :

    1. Permettre aux utilisateurs d'autoriser un tiers à accéder à leurs données.

    2. Vérifier que le tiers est bien celui qu’il prétend être.

  2. Onboarding : les banques ont besoin d'un moyen de réaliser l'onboarding des tiers et de vérifier qu'ils sont suffisamment dignes de confiance pour que les données de comptes personnels leurs soient divulguées.

  3. Accès : les tiers ont besoin d’un moyen d’accéder aux données des comptes des utilisateurs, et les banques d’un moyen de protéger ces données tout en garantissant qu’elles ne sont partagées qu’avec notre consentement.

Ces exigences constituent essentiellement un moyen d'établir à la fois le consentement et la confiance. Les deux doivent être réunis pour que tout écosystème d'Open Banking (ou d'API ouverte) prospère. Comprendre l'écosystème de l'Open Banking peut s'avérer complexe. Les deux diagrammes ci-dessous donnent une vue d'ensemble du fonctionnement de l'écosystème de l'Open Banking britannique et des principales interactions entre tous les participants.

Diagramme 1 : Écosystème de l'Open Banking britannique
Diagramme 1 : Écosystème de l'Open Banking britannique
Diagramme 2 : Établir le consentement et la confiance dans l'Open Banking britannique
Diagramme 2 : Établir le consentement et la confiance dans l'Open Banking britannique

 Au sein de l'écosystème Open Banking britannique, ForgeRock fait fonctionner deux composants avec :

  • ForgeRock Model Bank : Une banque modèle entièrement conforme qui fournit une application bancaire de référence, utilisée par les grandes banques et les tiers pour créer leurs propres applications conformément aux normes de l'Open Banking. (Voir l'annonce ici.)

  • ForgeRock Open Banking Directory : Une nouvelle version, entièrement conforme, de l'annuaire Open Banking du Royaume-Uni, qui sous-tend le sandbox de test et d'intégration. Contrairement au live directory de l'Open Banking, ForgeRock Open Banking Directory n'exige pas que les participants soient approuvés par la FCA, éliminant ainsi une barrière majeure à l'entrée.

Prise en charge des trois exigences et des spécifications de l'Open Banking britannique

Le Royaume-Uni a publié les spécifications lecture/écriture pour l'Open Banking. Celles-ci définissent les composants suivants, qui font partie intégrante des processus de consentement, d'onboarding et d'accès :

  • L'API de compte et transaction : terminaux, requêtes et réponses pour les demandes de compte.

  • L'API d'initiation de paiement : requêtes et réponses du terminal pour les demandes de paiement.

  • Profil de sécurité : les normes de sécurité qui soutiennent les API.

  • L'annuaire de l'Open Banking : le framework de confiance pour les participants à l'écosystème de l'Open Banking.

Ces spécifications sont extrêmement détaillées et nous vous recommandons fortement de les consulter pour vous familiariser avec le fonctionnement de l'Open Banking britannique.

Ce document vise toutefois à faire ressortir ce que, chez ForgeRock, nous considérons comme les éléments clés des spécifications, et à expliquer comment, avec ForgeRock, ils répondent aux trois exigences précédemment évoquées.

Encore une fois, ce document porte principalement sur le profil de sécurité et l'annuaire de l'Open Banking. Le consentement est la première exigence clé que nous aborderons, car l'onboarding est le résultat direct de la manière dont le consentement est collecté et appliqué.

Le consentement est un concept complexe qui repose sur trois mécanismes centraux : demander si le propriétaire des données d'un compte bancaire a accordé à sa banque l’autorisation de partager ces mêmes données, confirmer ce fait et imposer cette vérification. Ces mécanismes reposent sur des processus d'autorisation et d'authentification.

Autorisation

OAuth

OAuth 2.0 est la principale norme de sécurité pour l'autorisation déléguée et, selon l'Open Banking britannique, la solution idéale pour l'Open Banking. Si permettre à un utilisateur d'autoriser un tiers à agir en son nom posait jusqu'alors problème, OAuth apporte une solution.

OAuth est couramment utilisé pour permettre aux sites Web de partager des données entre eux. Il permet par exemple à Twitter de publier sur Facebook. Au lieu de partager les noms d'utilisateur et les mots de passe, un jeton d'accès OAuth est émis, qu'il suffit ensuite au tiers de présenter pour accéder aux données d'un utilisateur.

OAuth définit quatre rôles clés :

  • Propriétaire de la ressource : le propriétaire de la ressource à laquelle on accède

  • Serveur de ressources : serveur qui protège la ressource

  • Client : application souhaitant accéder à la ressource

  • Serveur d’autorisation : le serveur qui émet des jetons d’accès au client

Notez que le client doit être enregistré auprès du serveur d'autorisation avant d'initier le flux. Nous y reviendrons dans le cadre de l'onboarding.

Diagramme 3 : Flux du code d'autorisation OAuth
Diagramme 3 : Flux du code d'autorisation OAuth

OAuth utilise des champs d'application pour modéliser les autorisations demandées par le serveur de ressources. Le jeton d'accès émis est ensuite lié à ces champs d'application.

Les champs d'application sont relativement grossiers. On pourrait citer comme exemple : profil, image, publication. Les champs d'application ne sont pas détaillés, et certains sont généralement préconfigurés dans le serveur d’autorisation.

OAuth n'est qu'un framework, et l'Open Banking définit peu d'aspects de la manière dont OAuth doit être implémenté en toute sécurité. Par ailleurs, l'utilisation des champs d'application OAuth présente un problème pour l'Open Banking.

Diagramme 4 : Utilisation des champs d'application
Diagramme 4 : Utilisation des champs d'application

Comme vous pouvez le voir ci-dessus, les scopes devant être préconfigurés, il n'est pas approprié de modéliser les paiements en les utilisant. Nous allons résoudre ce problème avec OpenID Connect.

OAuth: https://tools.ietf.org/html/rfc6749

ForgeRock Docs: https://backstage.forgerock.com/docs/am/6/oauth2-guide/index.html

OpenID Connect

OpenID Connect (OIDC) est une norme reposant sur OAuth et dédiée à l'authentification déléguée. Dans OIDC, il existe trois rôles clés :

  • Partie de confiance : la partie qui délègue l'authentification à un fournisseur OpenID

  • Fournisseur OpenID : la partie responsable de l'authentification de l'utilisateur final

  • Utilisateur final : l'utilisateur lui-même

OpenID Connect permet à une partie de confiance de s’en remettre à un fournisseur d’identité pour authentifier les utilisateurs, par exemple en se connectant avec Facebook. La partie de confiance n'a pas à se préoccuper de la gestion des noms d'utilisateur et des mots de passe, elle se repose entièrement sur le fournisseur d'identité pour cet aspect. Le fournisseur d'identité renvoie ensuite un jeton d'identification que la partie de confiance peut utiliser pour confirmer l'identité de l'utilisateur.

Comme auparavant, le client doit être enregistré auprès du serveur d'autorisation avant d'initier le flux. Nous y reviendrons dans le cadre de l'onboarding.

Open ID Connect : http://openid.net/specs/openid-connect-core-1_0-final.html

Documents ForgeRock : https://backstage.forgerock.com/docs/am/6/oidc1-guide/index.html

Diagramme 5 : Flux du code d'autorisation OpenID Connect
Diagramme 5 : Flux du code d'autorisation OpenID Connect

La spécification OpenID Connect (OIDC) définit un élément appelé le paramètre de requête de revendications. Il peut être utilisé pour demander le renvoi de revendications spécifiques dans le jeton d'identification. Par ailleurs, la spécification OIDC permet surtout à la requête de spécifier les propriétés des revendications demandées. Cela nous permet de résoudre le problème du champ d'application évoqué plus haut, car nous pouvons désormais utiliser le paramètre de requête de revendications OIDC pour demander une autorisation pour des propriétés spécifiques. Le paramètre de requête nous permet également de signer la demande, ce qui nous permet de détecter si elle a été altérée.

Voici ce à quoi ressemble le paramètre de revendications dans le flux de l'Open Banking britannique :

{
    "alg": "RS256",
    "kid": "GxlIiwianVqsDuushgjE0OTUxOTk"
}
.
{
   "aud": "https://api.alphanbank.com",
   "iss": "s6BhdRkqt3",
   "response_type": "code id_token",
   "client_id": "s6BhdRkqt3",
   "redirect_uri": "https://api.mytpp.com/cb",
   "scope": "openid payments accounts",
   "state": "af0ifjsldkj",
   "nonce": "n-0S6_WzA2Mj",
   "max_age": 86400,
   "claims":
    {
     "userinfo":
      {
       "openbanking_intent_id": {"value": "urn:alphabank-intent-58923", "essential": true}
      },
     "id_token":
      {
       "openbanking_intent_id": {"value": "urn-alphabank-intent-58923", "essential": true},
       "acr": {"essential": true,
                "values": ["urn:openbanking:psd2:sca",
                     "urn:openbanking:psd2:ca"]}}
      }
    }
}

La partie importante du paramètre de revendications est openbanking_intent_id. C'est ainsi que nous résolvons le problème du champ d'application.

Diagramme 6 : Utilisation du paramètre de requête de revendications
Diagramme 6 : Utilisation du paramètre de requête de revendications

Nous avons mentionné plus tôt l'intérêt d'OIDC pour l'authentification déléguée, mais ce n'est pas le problème que nous essayons de résoudre avec l'Open Banking. Dans le contexte de l'Open Banking, nous ne nous reposons pas sur le jeton d'identification pour authentifier un utilisateur. Au lieu de cela, nous utilisons le jeton comme signature détachée à la réponse d'autorisation conformément à la spécification FAPI (API financière). Il s'agit d'une solution élégante à notre problème antérieur concernant les champs d'application. Elle nous permet de nous aligner sur le modèle FAPI pour la sécurité des API financières, qui repose largement sur l'utilisation d'OIDC.

ForgeRock Identity Platform prend entièrement en charge OAuth et OIDC, y compris le paramètre de requête OOTB.

FAPI: http://openid.net/wg/fapi/

Signature détachée : http://openid.net/specs/openid-financial-api-part-2-wd-02.html

Paramètre de revendications : http://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter

ForgeRock Docs: https://backstage.forgerock.com/docs/am/6/oidc1-guide/index.html#global-oauth-oidc-advanced-openid-connect

Spécification FAPI (API financière)

La spécification API financière (FAPI) est un projet de norme pour la configuration de solutions de sécurité pour les API financières. Elle définit les flux recommandés, les paramètres de configuration, et les algorithmes de signature et de chiffrement pour les implémentations OAuth et OIDC, afin d'améliorer la sécurité et de limiter les risques et les attaques connus. Elle ajoute également des contrôles de sécurité supplémentaires autour de toutes les demandes et réponses liées à l'Open Banking.

FAPI Headers: https://openid.net/specs/openid-financial-api-part-1.html

Requête en deux étapes

L'Open Banking utilise un mécanisme de demande en deux étapes, dans le cadre duquel une demande de paiement ou de compte est d'abord soumise avant d'être autorisée.

Diagramme 7 : Requête en deux étapes
Diagramme 7 : Requête en deux étapes

Le tiers envoie une intention de paiement ou de compte, qui représente la requête à laquelle l'utilisateur sera invité à consentir lors de l'étape d'autorisation suivante. La banque peut alors présenter ces informations à l'utilisateur au moment de la collecte du consentement, afin qu'il comprenne clairement ce qu'il accepte.

Authentification mutuelle TLS

Le terminal OAuth utilisé pour émettre des jetons d'accès au tiers est protégé par l'authentification mutuelle TLS (mTLS). Les tiers doivent utiliser le certificat de transport qui leur est délivré par l'annuaire afin d'échanger un code d'autorisation contre un jeton d'accès. La banque s'assurera également que le certificat TLS utilisé correspond à celui du client OAuth.

Authentification

Lorsque la banque reçoit une requête OAuth/OIDC pour autoriser un paiement, elle doit d'abord identifier l'utilisateur et vérifier qu'il est bien celui qu'il prétend être. La spécification Open Banking britannique ne précise pas comment cela doit être réalisé. La directive PSD2, en revanche, attend une authentification forte du client. Bien que nous ayons désactivé cette option dans notre environnement de référence pour simplifier l'expérience des développeurs, vous aurez en réalité besoin d'une approche robuste et fiable pour authentifier vos clients en utilisant au moins deux des trois facteurs que sont la connaissance, la possession et l'héritage.

Dans ForgeRock Identity Platform, la fonctionnalité Intelligent Authentication satisfait à cette exigence et vous permet d'aller au-delà en tenant compte d'une série de facteurs contextuels, comportementaux et basés sur les risques au cours du processus d'authentification.

ForgeRock Intelligent Authentication Flow
ForgeRock Intelligent Authentication Flow

ForgeRock Docs:: https://backstage.forgerock.com/docs/am/6/authentication-guide/#sec-configure-authentication-trees

Consentement

Enfin, l'utilisateur doit être invité à donner son consentement. La banque doit indiquer clairement ce à quoi l'utilisateur consent, et lui offrir la possibilité d'accepter ou de refuser de donner son consentement. Ces informations doivent être claires et concises.

Service de consentement à distance

ForgeRock Identity Platform OOTB offre un écran de consentement OAuth standard. Par son engagement actif à fournir aux banques des solutions d'Open Banking, ForgeRock a réalisé que cet écran de base ne serait pas suffisant. Par conséquent, nous avons introduit le concept d'un service de consentement à distance (RCS pour Remote Consent Service) à ForgeRock Identity Platform. Le RCS permet à la plateforme de s'en remettre à un autre service pour présenter une requête de consentement et recueillir le résultat, offrant ainsi une interface de consentement plus riche qui, par exemple, peut permettre au client de choisir le compte bancaire à utiliser pour un paiement.

Lors de la collecte du consentement, le service de consentement à distance renvoie le résultat à ForgeRock Identity Platform, qui émet un code d'autorisation conformément au flux OAuth.

Documentation: https://backstage.forgerock.com/docs/am/6/oauth2-guide/#oauth2-implement-remote-consent

onboarding

Maintenant que nous disposons d'un mécanisme de collecte du consentement, nous avons besoin d'un moyen de réaliser l'onboarding et de vérifier en toute sécurité les tiers qui souhaitent accéder aux données des comptes. C'est ici que l'annuaire entre en jeu.

L'annuaire

L’Open Banking Directory sert de plateforme centrale permettant de vérifier les banques et les tiers qui sont autorisés à prendre part à l’écosystème de l'Open Banking britannique. L'approbation de la Financial Conduct Authority (FCA) ne peut être obtenue sans enregistrement auprès de la version en ligne de l'Open Banking Directory. Cependant, le nouvel environnement sandbox d'annuaire fourni par ForgeRock ne présente pas ce type de restriction et constitue une solution entièrement conforme.

L'Open Banking Directory remplit plusieurs fonctions clés pour l'écosystème de l'Open Banking, notamment :

  • Possibilité pour les tiers et les banques d’enregistrer leurs coordonnées et leurs paramètres OAuth, tels que les terminaux bien connus et les redirect_url

  • Émission de clés de signature, de chiffrement et de transport à utiliser par des tiers lors de l'onboarding auprès des banques, formulation de requêtes d'autorisation, et accès aux données

  • Émission des Software Statement Assertions (SSA), les éléments de preuve que les tiers présenteront aux banques pour assurer leur onboarding en tant que participants vérifiés

  • Hébergement des terminaux JSON Web Key (JWK) utilisés pour vérifier les signatures Web JSON (JWS)

  • Téléchargement des clés dans plusieurs formats : JWK, PEM ou .key

Diagramme 8 : L'Open Banking Directory
Diagramme 8 : L'Open Banking Directory

 

Certificats

Trois types de certificats différents sont émis par l'annuaire :

  1. Signature : les certificats de signature sont utilisés pour créer des JWS afin de signer des charges utiles JSON Web Token (JWT) lors des processus d'onboarding et d'autorisation.
     

  2. Chiffrement : les certificats de chiffrement sont utilisés pour chiffrer les charges utiles JWT et les jetons d'identification. Par exemple, si vous souhaitez recevoir un jeton d'identification chiffré, la banque utilisera votre certificat de chiffrement pour chiffrer le JWS.


// JOSEHeader : en-tête de signature et chiffrement d'objet JSON 
// json : le contenu du JWT à signer et chiffrer 
// privateKey : la clé privée


payload = base64Encode ( JOSEHeader ) + “.” +base64Encode(json) 
signedAndEncodedPayload = base64Encode (encrypt(privateKey, payload)) 
JSW = payload + “.” + signedAndEncodedPayload

Processus de création JWS
  1. Transport : l'authentification mTLS permet de chiffrer les requêtes et les réponses entre les tiers et les banques à l'aide de certificats de transport délivrés par l'annuaire.

Software Statement Assertions et enregistrement dynamique des clients

Les Software Statement Assertions (SSA) font partie du protocole OAuth 2.0 d'enregistrement dynamique des clients. L'enregistrement dynamique des clients est un mécanisme qui permet aux clients OAuth d'être enregistrés et créés automatiquement à la réception d'un élément de preuve (la SSA). Ainsi, les tiers peuvent bénéficier d'un onboarding rapide auprès des banques et recevoir un identifiant client qu'ils pourront utiliser ultérieurement.

Voici à quoi ressemble une SSA une fois décodée :

JWT Header
{
  "kid": "e0f8da35-05c4-42a5-96ee-bf48a4924fa2",
  "alg": "RS256"
}
JWT Claims
{
  "org_jwks_endpoint": "TODO",
  "software_mode": "TEST",
  "software_redirect_uris": [
    "http://example.com/redirect"
  ],
  "org_status": "Active",
  "software_client_id": "5b11771fdecdcd0648d063e3",
  "iss": "ForgeRock",
  "software_tos_uri": "http://example.com/terms.html",
  "software_client_description": "Third Party Description",
  "software_jwks_endpoint": "https://service.directory.integ-ob.forgerock.financial/directory-services/api/software-statement/5b11771fdecdcd0648d063e3/application/jwk_uri",
  "software_policy_uri": "http://example.com/policy.html",
  "software_id": "5b11771fdecdcd0648d063e3",
  "org_contacts": [],
  "ob_registry_tos": "https://directory.integ-ob.forgerock.financial/tos/",
  "org_id": "5b117707decdcd0648d063e2",
  "software_logo_uri": "http://example.com/logo.jpg",
  "software_jwks_revoked_endpoint": "TODO",
  "software_roles": [
    "AISP",
    "PISP"
  ],
  "exp": 1528476229,
  "org_name": "[email protected]",
  "org_jwks_revoked_endpoint": "TODO",
  "iat": 1527871429,
  "jti": "24a4f5f6-e85d-4654-b288-e3eaa132587f"
}
Exemple de SSA décodée

 

Création d'une SSA à l'aide de ForgeRock Open Banking Directory
Création d'une SSA à l'aide de ForgeRock Open Banking Directory

La création d'une SSA est une étape nécessaire pour interagir avec l'écosystème de l'Open Banking. Si vous souhaitez en créer une vous-même, vous pouvez utiliser le nouvel annuaire ForgeRock Open Banking Directory : https://directory.ob.forgerock.financial/

Enregistrement dynamique des clients : https://tools.ietf.org/html/rfc7591

Enregistrer un prestataire tiers : https://backstage.forgerock.com/knowledge/openbanking/article/a39093356

ForgeRock Docs: https://backstage.forgerock.com/docs/am/6/oauth2-guide/#register-oauth2-client-dynamic

Habituellement, pour démarrer un flux OAuth ou OIDC, le tiers doit disposer d'un ensemble d'identifiants. En général, avec les clients OAuth, un identifiant client et un secret sont émis pour le tiers. Toutefois, il s'agit de l'un des divers mécanismes d'authentification disponibles dans la spécification OIDC. Dans notre implémentation bancaire de référence, nous avons choisi la méthode d'authentification private_key_jwt.

Avec private_key_jwt, plutôt que d'utiliser un identifiant client explicite et un secret, la clé avec laquelle vous signez votre JWT vous sert d'identifiant. Une fois l'onboarding réussi avec une SSA, le serveur d'autorisation reliera votre JWK URI au nouveau client OIDC. Lors de la réception de futures requêtes OIDC, le serveur d'autorisation vérifiera la signature des correspondances JWT et l'« objet » revendiqué de votre requête.

Clé Web Json

Json Web Key (JWK) est le format utilisé dans OIDC pour publier vos clés publiques auprès d'un tiers. Lorsque vous publiez vos clés en tant que JWK, le format utilisé pour partager plusieurs clés est appelé jwk_uri. Le répertoire jwk_uri constitue un bon exemple de ce format. Comme toute application, le répertoire publie également ses clés en tant que jwk_uri : https://service.directory.ob.forgerock.financial/directory-services/api/directory/keys/jwk_uri

La publication de vos clés publiques au format jwk_uri est obligatoire, car un tiers aura besoin de vérifier les JWT que vous avez signés ou d'utiliser vos clés publiques pour chiffrer les JWT qui ne peuvent être lus que par vous. À l'heure actuelle, l'annuaire gère cet aspect pour le compte des prestataires tiers.

Authentification mutuelle TLS

Les terminaux des banques sont protégés par mTLS. Cela signifie que si vous devez utiliser une API nécessitant un certain niveau d'autorisation, vous devrez vous assurer d'avoir configuré votre certificat de transport en conséquence.

mTLS constitue le même mécanisme que nous avons choisi de mettre en œuvre pour protéger l'API REST de notre annuaire et notre API REST JWKMS (service de gestion JWK).

D’autres contrôles de sécurité seront effectués par le prestataire de services de paiement si nécessaire, à l’aide de votre certificat de transport. Par exemple, lorsque vous enregistrez votre application à l'aide d'une assertion SSA, le serveur de ressources vérifie que le certificat de transport correspond aux revendications de la SSA.

ForgeRock Open Banking Directory : L'annuaire est un composant clé de l'écosystème de l'Open Banking. Cependant, l'annuaire en ligne nécessite que le tiers s'enregistre et se soumette à l'approbation de la Financial Conduct Authority (FCA), ce qui peut prendre plusieurs semaines et constitue une barrière à l'entrée significative pour les tiers qui veulent développer des services d'Open Banking.

ForgeRock Open Banking Directory a été développé pour résoudre ce problème. Il s'agit d'un annuaire entièrement conforme disposant des mêmes fonctionnalités que l'annuaire en ligne, mais toute personne souhaitant y accéder peut le faire immédiatement. De plus, nous avons enrichi l'annuaire avec un certain nombre de services utiles pour aider les développeurs à tester leurs intégrations, tels que les JWKMS.

JWKMS : JWKMS est un service adjacent à l'annuaire. En utilisant les clés générées pour vous par l'annuaire, il vous permet de manipuler les JWT en votre nom et fournit les fonctionnalités suivantes :

  • Test de votre configuration mTLS

  • Provide your keys in a JWK_URI format

  • Signature des revendications en tant que JWS

  • Signature, puis chiffrement des revendications en tant que JWE (JWS)

  • Déchiffrement de JWE

  • Validation de JWT

  • Rotation des clés

  • Réinitialisation des clés

En plus de ce qui précède, le JWKMS implémente également un mécanisme de rotation des clés qui est requis pour toute configuration OIDC utilisant des clés asymétriques.

Toutes les fonctionnalités JWKMS mentionnées ci-dessus ont été exposées par le biais d'API et nous permettent d'offrir aux développeurs une expérience totalement exempte de code lorsqu'ils apprennent à se familiariser avec les API de l'Open Banking.

Accès

Nous disposons désormais d'un mécanisme sécurisé et basé sur des normes pour collecter le consentement et réaliser l'onboarding des tiers avec un niveau de garantie très élevé. La dernière pièce du puzzle consiste à fournir un moyen pour les tiers d'accéder aux API de paiement et de compte. Généralement, cela se fait par le biais d'une passerelle d'API qui valide le jeton d'accès émis dans le flux de demande d'autorisation.

Les passerelles présentent deux manières de valider les jetons d'accès en fonction de l'architecture des jetons. La spécification n'a pas valeur de norme ici :

  • Avec état : si des jetons d'accès avec état sont utilisés, la passerelle d'API devra invoquer un terminalsur le serveur d'autorisation pour valider le jeton.

  • Sans état : si un jeton d'accès sans état est utilisé, la passerelle d'API utilisera le JWK_URI pour vérifier la signature du jeton.

Authentification mutuelle TLS

L'authentification mutuelle TLS (mTLS) est à nouveau utilisée lorsqu'un tiers accède à l'API. La passerelle d'API doit également vérifier que les détails du tiers inclus dans le certificat de transport utilisé pour accéder aux points de terminaison de l'API correspondent aux détails du tiers dans le certificat utilisé pour signer le jeton d'accès.

FAPI

Les recommandations FAPI sont appliquées lors de l’envoi de requêtes à l’API. La FAPI définit un certain nombre d'en-têtes supplémentaires qui doivent être configurés et aident à fournir un identifiant cohérent tout au long de l'interaction, tout en capturant des données supplémentaires, telles que l'adresse IP à partir de laquelle le client se connecte et la dernière fois où il s'est connecté, des informations importantes en termes de sécurité et d'audit.

Résumé

Dans ce document, nous avons abordé les principales caractéristiques de sécurité de ForgeRock qui permettent de se conformer à la spécification Open Banking britannique en matière de consentement et de fiabilité. ForgeRock Identity Platform, qui inclut ForgeRock Model Bank et ForgeRock Open Banking Directory, permet aux tiers et aux banques d'effectuer des tests et intégrations au sein de l'écosystème de l'Open Banking. Avec une compréhension approfondie du fonctionnement de l'écosystème, vous pouvez créer un tiers, réaliser l'onboarding auprès de l'annuaire et tester les flux de l'Open Banking dans l'environnement sandbox de l'annuaire ForgeRock.

En savoir plus sur ForgeRock Open Banking pour votre entreprise

ForgeRock est le leader des solutions de gestion des identités et de la confiance numériques, conçues pour soutenir l'Open Banking, sécuriser votre entreprise, renforcer la confiance et la fidélité de vos clients, et accroître vos opportunités commerciales ainsi que vos revenus dès aujourd'hui et pour longtemps.

Contactez-nous pour en savoir plus sur la façon dont ForgeRock peut aider votre entreprise à soutenir l'Open Banking.

ForgeRock® est l'éditeur de solutions de gestion des identités et des accès numériques qui transforme la façon dont les entreprises interagissent en toute sécurité avec leurs clients, employés, appareils et objets. Les organisations adoptent ForgeRock Identity Platform™ en tant que système d'enregistrement des identités numériques pour monétiser les relations avec leurs clients, respecter des réglementations strictes en matière de confidentialité et de consentement (RGPD, HIPAA, règles de confidentialité de la FCC, etc.) et tirer parti de l'Internet des Objets. Des centaines de marques ont adopté ForgeRock, dont Morningstar, Vodafone, GEICO, Toyota, TomTom et Pearson, ainsi que des administrations comme la Norvège, le Canada et la Belgique, qui sécurisent ainsi des milliards d'identités à travers le monde. ForgeRock possède des bureaux en Europe, aux États-Unis et en Asie.

Glossaire

AISP - Account Information Service Provider

ASPSP - Account Servicing Payment Service Providers, e.g. banks

API - Application Programming Interface

FAPI - Financial API Working Group

FCA - Financial Conduct Authority

JWE - JSON Web Encryption

JWK - JSON Web Key

JWKMS - JWK Management Service

JWS - JSON Web Signature

JWT - JSON Web Token

MATLS - Mutual Authentication TLS

OB - Open Banking

OIDC - OpenID Connect

PISP - Payment Initiation Service Provider

PSD2 - Payment Services Directive 2

REST - Representational State Transfer

RS - Resource Server

SSA - Software Statement Assertion

TLS - Transport Layer Security

TPP - Third Party Provider