Baza de cunoștințe OpenBanking UK
Activitatea bancară se confruntă cu o schimbare majoră, cererea utilizatorilor pentru acces sporit la cont și schimbul de informații despre cont. Pentru a proteja consumatorii, au fost scrise reglementări care să impună modul în care datele financiare pot fi create, accesate și partajate.
În această lucrare, discutăm la nivel tehnic modul în care bankIO permite Specificația Open Banking din Regatul Unit prin link-ul bankIO .
Trei cerințe cheie pentru activități Open Banking
Open Banking se referă la utilizatorii care își partajează datele bancare prin API-uri. Desigur, cu cât accesul terților este mai mare, cu atât riscul este mai mare.
Există trei cerințe cheie care se aplică securizării oricărei arhitecturi a ecosistemului Open Banking .
1. Consimțământ : băncile au nevoie de o modalitate de a confirma faptul că un utilizator a acordat consimțământul pentru partajarea datelor, ceea ce înseamnă, la rândul său, că are nevoie de o modalitate de a:
A. Permiteți utilizatorilor să autorizeze o terță parte să își acceseze datele.
b. Autentificați că terțul este cine pretinde că este.
- Onboarding: Banks need a way to onboard and verify that third parties are to be trusted with personal account data.
- Access: Third parties need a way to access user account data, and banks need a way to protect that data and enforce that it is only accessed with our consent.
În esență, aceste cerințe sunt un mijloc de stabilire atât a consimțământului , cât și a încrederii . Toate trebuie îndeplinite pentru ca orice ecosistem Open Banking (sau API deschis) să aibă succes. Înțelegerea ecosistemului Open Banking poate fi complexă. Cele două diagrame de mai jos oferă o imagine de nivel înalt a modului în care funcționează ecosistemul general al UK Open Banking și a interacțiunilor cheie dintre toți participanții.
Sprijinirea celor trei cerințe și a specificațiilor Open Banking din Regatul Unit
Marea Britanie a publicat Specificațiile de citire / scriere pentru activități Open Banking . Specificațiile definesc următoarele componente importante care sunt integrale pentru consimțământ, integrare și acces:
- Account and Transaction API: The endpoints, requests and responses for account requests.
- Payment Initiation API: The endpoint requests and responses for payment requests.
- Security Profile: The security standards that underpin the APIs.
- Open Banking Directory: The trust framework for participants in the Open Banking ecosystem.
Specificațiile sunt extrem de detaliate și le recomandăm cu tărie pentru a vă ajuta să înțelegeți cum funcționează UK Open Banking .
Cu toate acestea, intenția acestei lucrări este de a extrage ceea ce credem noi la bankIO sunt elementele cheie ale specificațiilor și de a explica modul în care acestea și bankIO abordează cele trei cerințe discutate anterior.
Din nou, ne concentrăm în primul rând pe Profilul de securitate și pe Open Banking Directory din această lucrare. Consimțământul este prima cerință cheie pe care o vom acoperi, deoarece integrarea este un rezultat direct al modului în care consimțământul este colectat și pus în aplicare.
Consimţământ
Consimțământul este un concept complex. Solicitarea, captarea și punerea în aplicare a faptului că proprietarul datelor contului bancar a acordat băncii permisiunea de a partaja aceste date sunt mecanisme esențiale. Aceste mecanisme se bazează pe autorizare și autentificare.
Autorizare
OAuth
OAuth 2.0 este standardul principal de securitate pentru autorizarea delegată, iar UK Open Banking a stabilit că este soluția potrivită pentru Open Banking. OAuth rezolvă problema de a permite unui utilizator să permită unei terțe părți să acționeze în numele lor.
OAuth este utilizat în mod obișnuit pentru a permite site-urilor web să partajeze date unul cu celălalt, cum ar fi permiterea Twitter pentru a posta pe Facebook. În loc să partajați nume de utilizator și parole, este emis un simbol de acces OAuth pe care terțul îl poate prezenta pentru a accesa datele unui utilizator.
OAuth definește patru roluri cheie:
- Proprietar de resurse: actorul care deține resursa la care se accesează
- Server de resurse: serverul care protejează resursa
- Client: aplicația care dorește să acceseze resursa
- Server de autorizare: serverul care emite jetoane de acces către client
Rețineți că clientul trebuie să fie înregistrat la serverul de autorizare înainte de a iniția fluxul, vom acoperi acest lucru mai târziu la bord.
OAuth utilizează domenii pentru a modela permisiunile solicitate de serverul de resurse, token-ul de acces emis este apoi legat de aceste domenii.
Domeniile de aplicare sunt relativ grosiere. Exemple tipice de domenii ar putea fi: profil, imagine, postare. Nu sunt grâne fine și un set de domenii sunt de obicei preconfigurate în serverul de autorizare.
OAuth este doar un cadru, iar Open Banking nu definește multe aspecte ale modului în care OAuth ar trebui implementat în siguranță. În plus, utilizarea domeniilor OAuth prezintă o problemă pentru Open Banking.
Deoarece domeniile trebuie preconfigurate, nu este adecvat să modelați plățile folosindu-le. Vom aborda acest lucru cu OpenID Connect.
OpenID Connect
OpenID Connect (OIDC) este un standard construit deasupra OAuth pentru autentificare delegată. În OIDC există trei roluri cheie:
- Relying Party: partea care delegă autentificarea unui furnizor OpenID
- Furnizor OpenID: partea responsabilă cu autentificarea utilizatorului final
- Utilizator final: utilizatorul însuși
OpenID Connect permite unei părți care se bazează să meargă la un furnizor de identitate pentru a autentifica utilizatorii, cum ar fi conectarea cu Facebook. Partea care se bazează nu trebuie să fie preocupată de gestionarea numelor de utilizator și a parolelor, ci are încredere în furnizorul de identitate pentru a face acest lucru. Furnizorul de identitate returnează apoi un indicativ de identificare pe care partea care se bazează îl poate folosi pentru a afirma identitatea utilizatorului.
Rețineți că, ca înainte, clientul trebuie să fie înregistrat la serverul de autorizare înainte de a iniția fluxul. Vom aborda acest lucru la bord mai târziu.
Open ID Connect: http://openid.net/specs/openid-connect-core-1_0-final.html
Specificația OpenID Connect (OIDC) definește un element numit parametru cerere revendicări . Parametrul poate fi utilizat pentru a solicita returnarea revendicărilor specifice în simbolul ID. În mod crucial, specificația OIDC permite, de asemenea, cererii de a specifica proprietățile revendicărilor solicitate. Acest lucru ne permite să rezolvăm problema domeniului de aplicare discutat mai sus, deoarece acum putem folosi parametrul OIDC de solicitare a revendicărilor pentru a solicita autorizarea pentru proprietăți specifice. Parametrul de solicitare ne permite, de asemenea, să semnăm cererea, ceea ce ne asigură că putem detecta dacă a fost modificată.
Mai jos este aspectul parametrului revendicărilor în fluxul de Open Banking din Regatul Unit:
Partea importantă a parametrului revendicărilor este openbanking_intent_id.
Am menționat mai devreme că OIDC este preocupat de autentificarea delegată, totuși nu aceasta este problema pe care încercăm să o rezolvăm cu Open Banking. În contextul Open Banking, nu ne bazăm pe simbolul ID pentru a autentifica un utilizator. În schimb, folosim simbolul ca semnătură detașată la răspunsul de autorizare conform specificației FAPI (API financiar). Aceasta este o soluție elegantă la problema noastră anterioară cu domeniile de aplicare și ne permite să ne aliniem cu modelul FAPI pentru securitatea API-ului financiar, care utilizează pe larg OIDC.
FAPI: http://openid.net/wg/fapi/
Semnătură detașată: http://openid.net/specs/openid-financial-api-part-2-wd-02.html
Parametru revendicări: http://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter
Specificații API financiare
Specificația API-ului financiar (FAPI) este un proiect de standard pentru configurarea soluțiilor de securitate a API-ului financiar. Acesta definește fluxurile recomandate, parametrii de configurare și algoritmii de semnare și criptare pentru implementările OAuth și OIDC pentru a spori securitatea și a atenua riscurile și atacurile cunoscute. De asemenea, adaugă controale de securitate suplimentare în jurul tuturor cererilor și răspunsurilor Open Banking .
Anteturi FAPI: https://openid.net/specs/openid-financial-api-part-1.html
Cerere în două etape
Open Banking folosește un mecanism de solicitare în două etape în care o cerere de plată sau de cont este organizată mai întâi înainte de a fi autorizată.
Terțul părți trimite o intenție de plată sau de cont care reprezintă solicitarea căreia utilizatorul i se va cere să consimtă în următorul pas de autorizare. Banca poate prezenta aceste informații utilizatorului în momentul consimțământului, astfel încât să înțeleagă în mod clar la ce sunt de acord.
Autentificare reciprocă TLS
Punctul final OAuth utilizat pentru a emite jetoane de acces către terți este protejat de autentificare reciprocă TLS (MATLS). Terțele părți trebuie să utilizeze certificatul de transport eliberat de director pentru a schimba un cod de autorizare pentru un token de acces. De asemenea, banca se va asigura că certificatul TLS utilizat se potrivește cu cel al clientului OAuth.
Autentificare
Când banca primește o solicitare OAuth / OIDC de autorizare a plății, trebuie mai întâi să identifice utilizatorul și să verifice dacă sunt cine pretind că sunt. Specificațiile Open Banking din Regatul Unit nu menționează cum trebuie realizat acest lucru. PSD2 se așteaptă totuși o autentificare puternică a clienților. Deși am dezactivat acest lucru în mediul nostru de referință pentru a simplifica experiența dezvoltatorului, în realitate veți avea nevoie de o abordare solidă și fiabilă pentru autentificarea clienților folosind cel puțin două dintre cele trei elemente ale cunoștințelor: posesia și inerența.
Autentificarea inteligentă în bankIO Link îndeplinește această cerință și vă permite să treceți dincolo de aceasta și să țineți cont de o serie de factori contextuali, comportamentali și de risc pe parcursul procesului de autentificare.
Consimţământ
În cele din urmă, utilizatorul trebuie solicitat să consimtă. Banca trebuie să fie clară cu privire la ce consimte utilizatorul și să le ofere opțiunea de a aproba sau refuza consimțământul. Aceste informații trebuie să fie clare și concise.
Serviciu de consimțământ de la distanță
bankIO Link OOTB oferă un ecran de consimțământ OAuth standard. Fiind angajat activ cu băncile pentru a oferi soluții Open Banking/PSD2, bankIO a realizat că acest ecran de bază nu ar fi suficient. Drept urmare, am introdus conceptul de serviciu de consimțământ la distanță (RCS) în bankIO Link. RCS permite platformei să se amâne la un alt serviciu pentru a prezenta o cerere de consimțământ și a colecta rezultatul, permițând o interfață de consimțământ mai bogată care, de exemplu, poate permite unui client să aleagă ce cont bancar să utilizeze pentru o plată.
După obținerea consimțământului, RCS returnează rezultatul către link-ul bankIO , care emite un cod de autorizare conform fluxului OAuth.
La imbarcare
Acum că avem un mecanism de colectare a consimțământului, avem nevoie de o modalitate de a ne asigura în siguranță și de a verifica terții care doresc să acceseze datele contului. Aici intră în joc directorul.
Directorul
Directorul Open Banking servește drept platformă centrală pentru verificarea băncilor și a terților care sunt autorizați să participe la ecosistemul Open Banking al Regatului Unit. Înregistrarea în versiunea live a directorului Open Banking este condiționată de aprobarea de către Autoritatea de Conduită Financiară (FCA). Cu toate acestea, noul sandbox al directorului pe care îl oferă bankIO nu are astfel de restricții și este o soluție complet conformă.
Directorul Open Banking îndeplinește mai multe funcții cheie pentru ecosistemul Open Banking , cum ar fi:
- Allowing third parties and banks to register their details and OAuth parameters, such as redirect_url’s and well known endpoints
- Emiterea de chei de semnare, criptare și transport pentru utilizare de către terți atunci când se îmbarcă la bănci, face cereri de autorizare și accesează date
- Emiterea de declarații de declarații software (SSA), dovezile pe care terții le vor prezenta băncilor la bord ca participanți verificați
- Găzduirea punctelor finale JSON Web Key (JWK) utilizate pentru verificarea semnăturilor web JSON (JWS)
- Descărcarea cheilor în mai multe formate: JWK, PEM sau .key
Certificate
Trei tipuri diferite de certificate sunt emise de director:
- Signing: Signing certificates are used to create JWSs to sign JSON Web Token (JWT) payloads during both the onboarding and authorization processes.
- Encryption: Encryption certificates are used to encrypt the JWT payloads and for ID token encryption. For example, if you want to receive an encrypted ID token, the bank will use your encryption certificate to encrypt the JWS.
Procesul de creare JWS
- Transport: Mutual TLS is used to encrypt requests and responses between third parties and banks using transport certificates issued by the directory.
Afirmații ale declarației software și înregistrare dinamică a clienților
Afirmațiile privind declarațiile software (SSA) fac parte din Protocolul OAuth 2.0 Dynamic Client Registration Protocol. Înregistrarea dinamică a clienților este un mecanism care permite clienților OAuth să fie înregistrați și creați automat la bon fiscal unei dovezi (SSA). Acest lucru permite terților să se angajeze rapid la bănci și să primească un ID de client pe care îl pot folosi ulterior.
Așa arată un SSA atunci când este decodat:
Cu private_key_jwt, mai degrabă folosiți un ID de client explicit și un secret, cheia cu care vă semnați JWT vă servește de fapt drept acreditare. După integrarea cu succes cu un SSA, serverul de autorizare va conecta URI-ul dvs. JWK cu noul client OIDC. Când sunt primite cereri OIDC viitoare, serverul de autorizare verifică semnătura meciurilor JWT și revendicarea „subiect” în cererea dvs.
Cheie web Json
Json Web Key (JWK) este formatul utilizat în OIDC pentru a publica cheile dvs. publice către o terță parte. Când publicați cheile ca JWK, formatul utilizat pentru partajarea mai multor chei se numește jwk_uri. Un bun exemplu al acestui format este directorul jwk_uri. Ca orice aplicație, directorul își publică, de asemenea, cheile ca jwk_uri: <a>https: //service.directory.ob. bankIO.financial / directory-services / api / directory / keys / jwk \ _uri</a>
Publicarea cheilor publice într-un format jwk_uri este necesară, deoarece o terță parte ar trebui să verifice JWT-urile pe care le-ați semnat sau să utilizați cheile publice pentru a cripta JWT-urile care pot fi citite doar de dvs. În acest moment directorul gestionează acest lucru în numele TPP-urilor.
Autentificare reciprocă TLS
Punctele finale ale băncilor sunt protejate de MATLS. Aceasta înseamnă că, dacă trebuie să utilizați un API care necesită un anumit nivel de permisiuni, va trebui să vă asigurați că ați configurat certificatul de transport în consecință.
MATLS este același mecanism pe care l-am ales să îl implementăm pentru protejarea directorului REST API și a API-ului REST JWKMS (JWK Management Service).
Alte verificări de securitate vor fi efectuate de ASPSP atunci când este necesar, utilizând certificatul de transport. De exemplu, când vă înregistrați aplicația utilizând un SSA, RS va verifica dacă certificatul de transport corespunde revendicărilor SSA.
Acces
Acum avem un mecanism sigur, bazat pe standarde, pentru autorizarea consimțământului și integrarea terților la un nivel foarte ridicat de asigurare. Ultima piesă a puzzle-ului oferă un mijloc prin care terții pot accesa efectiv API-urile de plată și de cont. De obicei, acest lucru este furnizat de un gateway API care va valida token-ul de acces emis în fluxul de cerere de autorizare.
Gateway-urile au două moduri de a valida jetoanele de acces în funcție de arhitectura token-ului. Specificația nu este prescriptivă aici:
- Stateful: If stateful access tokens are being used then the API gateway will need to invoke an endpoint on the authorization server to validate the token.
- Stateless: If a stateless access token is being used, then the API gateway would make use of the JWK_URI to verify the signature of the token.
Autentificare reciprocă TLS
Mutual Authentication TLS (MATLS) este din nou utilizat atunci când o terță parte accesează API-ul. Gateway-ul API trebuie să verifice, de asemenea, dacă detaliile terței părți incluse în certificatul de transport utilizat pentru a accesa punctele finale API se potrivesc cu detaliile terței părți din certificatul utilizat pentru semnarea token-ului de acces.
FAPI
Recomandările FAPI sunt puse în aplicare atunci când faceți cereri către API. FAPI definește o serie de anteturi suplimentare care ar trebui să fie setate și să ajute la furnizarea unui identificator consecvent în întreaga interacțiune, în timp ce captează date suplimentare, cum ar fi adresa IP de la care se conectează clientul și ultima dată când s-a conectat, ceea ce este important din o perspectivă de securitate și audit.
Rezumat
În acest document am abordat principalele caracteristici de securitate bankIO care permit consimțământul și încrederea în specificația UK Open Banking . bankIO Link, care include bankIO Model Bank și bankIO Open Banking Directory, permite terților și băncilor să testeze și să se integreze în ecosistemul Open Banking . Cu o înțelegere la nivel înalt a modului în care funcționează ecosistemul, puteți crea o terță parte, la bord cu directorul și puteți testa fluxurile bancare deschise în bankIO directorului bankIO .
Glosar
AISP - Furnizor de servicii de informații despre cont
ASPSP - Furnizori de servicii de plată pentru deservirea contului, de ex. bănci
API - Interfață de programare a aplicațiilor
FAPI - Grupul de lucru API financiar
FCA - Autoritatea de conduită financiară
JWE - Criptare web JSON
JWK - Cheie web JSON
JWKMS - Serviciul de gestionare JWK
JWS - Semnătură web JSON
JWT - JSON Web Token
MATLS - Autentificare reciprocă TLS
OB - Open Banking
OIDC - OpenID Connect
PISP - Furnizor de servicii de inițiere a plății
PSD2 - Directiva privind serviciile de plată 2
REST - Transfer de stat reprezentativ
RS - Server de resurse
SSA - Afirmația declarației software
TLS - Transport Layer Security
TPP - Furnizor terț