The business of banking is undergoing a major shift with users demand for increased account access and the sharing of account information. To protect consumers, regulations have been written to mandate how financial data can be created, accessed, and shared.
In this paper, we discuss at a technical level how ForgeRock enables the UK Open Banking Specification through the ForgeRock Identity Platform™ and the delivery of both the reference bank and the new ForgeRock directory sandbox. This paper primarily focuses on Security Profile and the ForgeRock Open Banking Directory.
Throughout this document we have provided links to ForgeRock documentation for further explanation of the Open Banking functionality being discussed.
Three Key Requirements for Open Banking
Open Banking is all about users sharing their banking data through APIs. Of course, the more third-party access, the higher the risk.
There are three key requirements that apply to securing any Open Banking ecosystem architecture.
-
Consent: Banks need a way to confirm that a user has granted consent to data being shared which in turn means they need a way to:
-
Allow users to authorize a third party to access their data.
-
Authenticate that the third party is who they claim to be.
-
-
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.
In essence, these requirements are a means of establishing both consent and trust. All must be met for any Open Banking (or open API) ecosystem to succeed. Understanding the Open Banking ecosystem can be complex. The two diagrams below give a high level view of how the overall UK Open Banking ecosystem works and the key interactions between all participants.
Within the UK Open Banking ecosystem, ForgeRock powers two components with the following:
-
ForgeRock Model Bank: A fully compliant model bank that provides a Reference Bank Application, used by leading banks and third parties to build their own applications in accordance with Open Banking standards. (See announcement here.)
-
ForgeRock Open Banking Directory: A new, fully compliant version of the UK Open Banking Directory underpinning the testing and integration sandbox. Unlike the Open Banking live directory, ForgeRock Open Banking Directory does not require participants to be FCA approved, reducing a significant barrier to entry.
Supporting the Three Requirements and the UK Open Banking Specifications
The UK has published the Open Banking Read/Write Specifications. The Specifications define the following important components that are integral for consent, onboarding, and access:
-
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.
The specifications are extremely detailed and we highly recommend them to help you understand how UK Open Banking works.
The intent of this paper however, is to draw out what we at ForgeRock believe are the key elements of the specifications and to explain how they and ForgeRock address the three requirements discussed earlier.
Again, we primarily focus upon the Security Profile and the Open Banking Directory in this paper. Consent is the first key requirement we’ll cover, as onboarding is a direct result of how consent is collected and enforced.
Consent
Consent is a complex concept. Requesting, capturing, and enforcing that the owner of bank account data has granted permission to the bank to share that data are pivotal mechanisms. These mechanisms rely on authorization and authentication.
Authorization
OAuth
OAuth 2.0 is the leading security standard for delegated authorization and UK Open Banking has determined it is the right solution for Open Banking. OAuth solves the problem of enabling a user to allow a third party to act on their behalf.
OAuth is commonly used for permitting websites to share data with one another, such as allowing Twitter to post to Facebook. Instead of sharing usernames and passwords, an OAuth access token is issued that the third party can then present to access a user’s data.
OAuth defines four key roles:
-
Resource Owner: the actor who owns the resource that is being accessed
-
Resource Server: the server that protects the resource
-
Client: the application wanting to access the resource
-
Authorization Server: the server that issues access tokens to the client
Note that the client must be registered with the authorization server before initiating the flow, we will cover this later in onboarding.
OAuth uses scopes to model the permissions being requested by the resource server, the access token issued is then linked to these scopes.
Scopes are relatively coarse. Typical examples of scopes could be: profile, picture, post. They are not fine grain and a set of scopes are usually pre-configured in the authorization server.
OAuth is just a framework and Open Banking does not define many aspects of how OAuth should be securely implemented. In addition, the use of OAuth scopes presents a problem for Open Banking.
As you can see above, because scopes have to be pre-configured, it is not appropriate to model payments using them. We will address this with 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) is a standard built on top of OAuth for delegated authentication. In OIDC there are three key roles:
-
Relying Party: the party that is delegating authentication to an OpenID provider
-
OpenID Provider: the party responsible for authentication of the end user
-
End-User: the user themselves
OpenID Connect enables a relying party to defer to an identity provider to authenticate users, such as logging in with Facebook. The relying party does not have to be concerned with managing usernames and passwords, instead they trust the identity provider to do that. The identity provider then returns an ID token that the relying party can use to assert the user’s identity.
Note that as before, the client must be registered with the authorization server before initiating the flow. We will cover this in onboarding later.
|
Open ID Connect: http://openid.net/specs/openid-connect-core-1_0-final.html ForgeRock Docs: https://backstage.forgerock.com/docs/am/6/oidc1-guide/index.html |
The OpenID Connect (OIDC) specification defines an element called the claims request parameter. The parameter can be used to request that specific claims are returned in the ID token. Crucially, the OIDC specification also allows for the request to specify the properties of the claims being requested. This allows us to solve the scope problem discussed above because we can now use the OIDC claims request parameter to request authorization for specific properties. The request parameter also allows us to sign the request, which ensures that we can detect if it has been tampered with.
Below is what the claims parameter looks like in the UK Open Banking flow:
{
"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"]}}
}
}
}The important part of the claims parameter is the openbanking_intent_id. This is how we solve the scope problem.
We mentioned earlier that OIDC is concerned with delegated authentication, however that is not the problem we are trying to solve with Open Banking. In the context of Open Banking, we are not relying on the ID token to authenticate a user. Instead we are using the token as a detached signature to the authorization response as per the FAPI (Financial API) specification. This is an elegant solution to our earlier problem with scopes and allows us to align with the FAPI model for financial API security, which makes extensive use of OIDC.
The ForgeRock Identity Platform offers full support for OAuth and OIDC, including the request parameter, OOTB.
Financial API Specification
The Financial API Specification (FAPI) is a draft standard for configuring financial API security solutions. It defines recommended flows, configuration parameters, and signing and encryption algorithms for OAuth and OIDC implementations to enhance security and mitigate known risks and attacks. It also adds additional security controls around all Open Banking requests and responses.
|
FAPI Headers: https://openid.net/specs/openid-financial-api-part-1.html |
Two Stage Request
Open Banking uses a two stage request mechanism where a payment or account request is first staged before being authorized.
The third party sends a payment or account intent that represents the request that the user will be asked to consent to in the following authorization step. The bank can then present this information to the user at the time of consent so they clearly understand what it is they are agreeing to.
Mutual Authentication TLS
The OAuth endpoint used to issue access tokens to the third party is protected by Mutual Authentication TLS (MATLS). Third parties must use the transport certificate issued to them by the directory in order to exchange an authorization code for an access token. The bank will also ensure the TLS certificate being used matches that of the OAuth client.
Authentication
When the bank receives an OAuth/OIDC request to authorize a payment, they first need to identify the user and verify they are who they claim to be. The UK Open Banking specification does not state how this is to be achieved. PSD2 however, expects Strong Customer Authentication. Although we have turned this off in our reference environment to simplify the developer experience, in reality you will require a robust and reliable approach for authenticating customers using at least two of the three elements of knowledge: possession and inherence.
Intelligent Authentication in the ForgeRock Identity Platform satisfies this requirement and enables you to go beyond it and take into account a range of contextual, behavioural, and risk based factors during the authentication process.
|
ForgeRock Docs:: https://backstage.forgerock.com/docs/am/6/authentication-guide/#sec-configure-authentication-trees |
Consent
Finally the user must be asked to consent. The bank needs to be clear about what the user is consenting to and offer them the option to approve or deny consent. This information needs to be clear and concise.
Remote Consent Service
The ForgeRock Identity Platform OOTB offers a standard OAuth consent screen. Being actively engaged with banks to deliver Open Banking solutions, ForgeRock realised this basic screen would not be sufficient. As a result, we introduced the concept of a Remote Consent Service (RCS) into the ForgeRock Identity Platform. The RCS enables the platform to defer to another service to present a consent request and collect the result, enabling a richer consent interface that, for example, can allow a customer to choose which bank account to use for a payment.
Upon collecting consent, the RCS returns the result to the ForgeRock Identity Platform, which issues an authorization code as per the OAuth flow.
|
Documentation: https://backstage.forgerock.com/docs/am/6/oauth2-guide/#oauth2-implement-remote-consent |
Onboarding
Now that we have a mechanism for collecting consent, what we need is a way to securely onboard and verify the third parties who want to access account data. This is where the directory comes into play.
The Directory
The Open Banking Directory serves as the central platform for verifying the banks and third parties who are approved to partake in the UK Open Banking ecosystem. Registration on the live version of the Open Banking directory is contingent on being approved by the Financial Conduct Authority (FCA). However, the new directory sandbox that ForgeRock provides has no such restrictions and is a fully compliant solution.
The Open Banking Directory fulfills several key functions for the Open Banking ecosystem, such as:
-
Allowing third parties and banks to register their details and OAuth parameters, such as redirect_url’s and well known endpoints
-
Issuing signing, encryption, and transport keys for use by third parties when onboarding with banks, making authorization requests, and accessing data
-
Issuing Software Statement Assertions (SSAs), the items of proof that third parties will present to banks to onboard as verified participants
-
Hosting the JSON Web Key (JWK) endpoints used to verify JSON Web Signatures (JWS)
-
Downloading of keys in several formats: JWK, PEM or .key
Certificates
Three different types of certificates are issued by the directory:
-
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.
// JOSEHeader: JSON Object Signing and Encryption Header
// json: The Content of the JWT to sign and encrypt
// privateKey: The private key
payload = base64Encode ( JOSEHeader ) + “.” +base64Encode(json)
signedAndEncodedPayload = base64Encode (encrypt(privateKey, payload))
JSW = payload + “.” + signedAndEncodedPayload
-
Transport: Mutual TLS is used to encrypt requests and responses between third parties and banks using transport certificates issued by the directory.
Software Statement Assertions and Dynamic Client Registration
Software Statement Assertions (SSAs) are part of the OAuth 2.0 Dynamic Client Registration Protocol. Dynamic Client Registration is a mechanism that allows OAuth clients to be registered and created automatically upon receipt of an item of proof (SSA). This enables third parties to rapidly onboard with banks and receive a client ID they can use for later on.
This is what an SSA looks like when decoded:
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"
}
Creating an SSA is a necessary step for interacting with the Open Banking ecosystem. If you would like to create one yourself, you can use the new ForgeRock Open Banking Directory to do exactly that: https://directory.ob.forgerock.financial/
|
Dynamic Client Registration: https://tools.ietf.org/html/rfc7591 Registering a TPP: https://backstage.forgerock.com/knowledge/openbanking/article/a39093356 ForgeRock Docs: https://backstage.forgerock.com/docs/am/6/oauth2-guide/#register-oauth2-client-dynamic |
Usually, in order to commence an OAuth or OIDC flow, the third party must have a set of credentials. Typically with OAuth clients, a client ID and a secret is issued to the third party. However, this is one of several authentication mechanisms that are available in the OIDC specification. In our reference bank implementation we have chosen the private_key_jwt authentication method.
With private_key_jwt, rather then use an explicit client ID and a secret, the key with which you sign your JWT actually serves as your credential. Upon successful onboarding with an SSA, the authorization server will link your JWK URI with the new OIDC client. When future OIDC requests are received, the authorization server verifies the signature of the JWT matches and the “subject” claim in your request.
Json Web Key
Json Web Key (JWK) is the format used in OIDC to publish your public keys to a third party. When publishing your keys as a JWK, the format used for sharing multiple keys is called jwk_uri. A good example of this format is the directory jwk_uri. Like any application, the directory also publishes its keys as a jwk_uri: https://service.directory.ob.forgerock.financial/directory-services/api/directory/keys/jwk_uri
Publishing your public keys in a jwk_uri format is required as a third party would need to verify JWTs you have signed or use your public keys to encrypt JWTs that can only be read by you. At this time the directory manages this on behalf of TPPs.
Mutual Authentication TLS
The banks endpoints are protected by MATLS. This means that if you need to use an API that requires a certain level of permissions, you will need to make sure you have setup your transport certificate accordingly.
MATLS is the same mechanism we have chosen to implement for protecting our directory REST API and JWKMS (JWK Management Service) REST API.
Further security checks would be done by the ASPSP when required, using your transport certificate. For example, when you register your application using an SSA, the RS would verify that the transport certificate matches the SSA claims.
|
ForgeRock Open Banking Directory: The directory is a key component of the Open Banking ecosystem, however the live directory requires that the third party registers and works through approval from the Financial Conduct Authority (FCA), which can take a number of weeks and presents a significant barrier to entry for third parties who want to develop Open Banking services. ForgeRock Open Banking Directory was developed to solve this problem. It is a fully compliant directory with the same functionality as the live directory, however, it is immediately accessible to anyone who wants to access it. In addition we have augmented the directory with a number of useful services to aid developers in testing their integrations, such as the JWKms. JWKms: The JWKms is a service adjacent to the directory. Using the keys generated for you by the directory, it allows you to manipulate JWTs on your behalf and provides the following functionality:
In addition to the above, the JWKms also implements a key rotation mechanism which is required for any OIDC setup that makes use of asymmetric keys. All of the above JWKms functionality has been exposed through APIs and, as a result of this functionality, we can offer a developers a completely code free experience as they learn their way around the Open Banking APIs. |
Access
Now we have a secure, standards-based mechanism for authorizing consent and onboarding third parties to a very high level of assurance. The final piece of the puzzle is providing a means by which the third parties can actually access payment and account APIs. Typically, this is provided by an API Gateway which will validate the access token issued in the authorization request flow.
Gateways have two ways to validate access tokens depending on the token architecture. The specification is not prescriptive here:
-
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.
Mutual Authentication TLS
Mutual Authentication TLS (MATLS) is again used when a third party accesses the API. The API gateway needs to also check that the details of the third party included in the transport certificate used to access the API endpoints matches the details of the third party in the certificate used to sign the access token.
FAPI
FAPI recommendations are enforced when making requests to the API. FAPI defines a number of additional headers that should be set and help to provide a consistent identifier across the whole interaction, whilst capturing additional data such as the IP address the customer is logging in from and the last time they logged in, which is important from a security and audit perspective.
Summary
In this document we have touched upon the key ForgeRock security features that enable consent and trust in the UK Open Banking specification. The ForgeRock Identity Platform, which includes the ForgeRock Model Bank and ForgeRock Open Banking Directory, allow third parties and banks to test and integrate within the Open Banking ecosystem. With a high level understanding of how the ecosystem works, you can create a third party, onboard with the directory, and test the open banking flows in the ForgeRock directory sandbox.
Learn More About ForgeRock Open Banking for Your Organization
ForgeRock is the leader in digital identity and trust — designed to support Open Banking, secure the enterprise, build customer trust and loyalty, and grow business opportunities and revenue today and well into the future.
Contact us to learn more about how ForgeRock can help your organization support Open Banking.
ForgeRock® is the Digital Identity Management company transforming the way organizations interact securely with customers, employees, devices, and things. Organizations adopt the ForgeRock Identity Platform™ as their digital identity system of record to monetize customer relationships, address stringent regulations for privacy and consent (GDPR, HIPAA, FCC privacy, etc.), and leverage the internet of things. ForgeRock serves hundreds of brands, including Morningstar, Vodafone, GEICO, Toyota, TomTom, and Pearson, as well as governments like Norway, Canada, and Belgium, securing billions of identities worldwide. ForgeRock has offices across Europe, the USA, and Asia.
Glossary
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