Open Banking for OAuth Developers

Open Banking is the UK’s implementation of PSD2, a directive that aims to open banks up for collaboration and encourage competition. To achieve this, Open Banking uses OAuth 2, bringing its own set of extensions to the protocol and its own set of acronyms.

In this article, you will build upon your existing OAuth and OpenID Connect knowledge to learn about Open Banking’s architecture, its new acronyms, and what implementation is the best fit for you.

What is PSD2?

Before I get into the details, let’s have a quick recap on PSD2.

At a super high level, the revised Payment Services Directive (PSD2) is an EU Directive created to start opening banks up to collaboration and encourage competition. This means that banks must create open APIs so that third parties can access customer accounts and initiate payments.

To the end-user, there are some great benefits to this. They can:

• start using third party accounting apps to manage their finances
• use comparison apps to analyze your account to find better deals
• use a common, secure payment interface, without third parties taking a cut.

PSD2 vs. Open Banking

The idea behind PSD2 is great, but unfortunately, it has led to many different implementations, authentication methods, and API designs. As a result, while PSD2 was designed to open banks, they remain relatively closed and fragmented due to a lack of standardization.

The UK’s Open Banking implements PSD2, but it takes PSD2 further by adding technical requirements, such as OAuth and OpenID Connect. Open Banking worked closely with the OpenID Foundation and collaborated to create the Financial-grade API (FAPI), a standard suite of APIs that enable Open Banking members to collaborate.

Open Banking and OAuth

As you know, OAuth is the best way to protect your APIs and to allow users to authorize applications to act on their behalf. But Open Banking takes your typical, vanilla OAuth implementation and builds upon it with some newer specifications and its own set of acronyms.

With Open Banking, the bank acts as the authorization server, but in this case, it is known as an Account Servicing Payment Service Providers (ASPSP). This could be a bank, building society, or payment company.

Not only does the bank act as the authorization server, but it is also the protected resource, offering read and write APIs for accessing account data and processing payments.

Meanwhile, a client application can act in two different ways: as an Account Information Service Provider (AISP) or a Payment Initiation Service Provider (PISP).

The end-user is sometimes given a new acronym of PSU (Payment Services User), but they are still acting as the OAuth resource owner.

Account Information Service Provider (AISP)

AISPs are the accounting and comparison apps that I talked about earlier; applications that want to read your account data and provide some sort of added value. This can range from viewing transaction history and your balance, to creating standing orders and direct debits.

An AISP uses your typical OAuth flow, with a few caveats. In these examples, you will see the standard authorization request made in the browser using the authorization code grant. However, Open Banking also allows for the use of Client-Initiated Backchannel Authentication (CIBA).

1. The AISP (client app) creates an account access consent resource at the ASPSP (authorization server). This request requires an access token, requested using the client credentials grant
2. The ASPSP returns a consent ID to AISP
3. The AISP initiates an OAuth authorization request that contains the consent ID, redirecting the user to the ASPSP
4. The user authenticates and consents, and is redirected back to AISP along with an authorization code. Consent in this case also includes selecting which accounts the AISP can read
5. The AISP swaps the code for tokens
6. The AISP starts calling read-only APIs using the access token authorized by the user (e.g. /accounts and /accounts/{ID}/transactions)

It’s worth noting that in this flow, all backchannel communication uses Transport Layer Security (TLS) 1.2 mutual authentication.

To see the full set of read APIs available to AISPs, check out Open Banking’s Account and Transaction API.

Payment Initiation Service Provider (PISP)

PISPs are the online services that ask the user (the PSU) to authorize a payment from an account that the user owns, to a different account. These can be one-time payments or standing orders, with variants for both domestic and international payments.

A PISP uses a similar flow to the AISP, with an initial request that starts the process; however, a PISP also includes transaction-specific authorization and account selection.

1. The PISP (client app) creates a payment order consent resource at the ASPSP. This request:
   • requires an access token, requested using the client credentials grant
   • includes the amount to be paid
2. The ASPSP returns a consent ID to PISP
3. The PISP initiates an OAuth authorization request that contains the consent ID, redirecting the user to the ASPSP
4. The user authenticates and consents, and is redirected back to the PISP along with an authorization code. Consent in this case also includes selecting which account the payment should be made from
5. The PISP swaps the code for tokens
6. The PISP confirms that the user has the funds to make the payment by calling the funds confirmation endpoint at the ASPSP (this is only required for one-off payments)
7. The PISP creates a payment order resource at the ASPSP

In this process, the PISP is issued an access token scoped to this single payment, where it can create the payment order authorized by the user and then, optionally, check the status of the payment order.

To see the full set of read APIs available to PISPs, check out Open Banking’s Payment Initiation API.

How Do You Implement Open Banking?

To implement Open Banking in your organization, you have a few options. You can do it yourself™ or use an identity provider. If you are an AISP or PISP, you also have the option of using a Trusted Service Provider (TSP).

Do It Yourself

As an Account Servicing Payment Service Providers (ASPSP, the authorization server), doing it yourself means taking a vanilla OAuth/OpenID Connect platform such as IdentityServer and extending it to handle the FAPI security profile. You would also need to implement the read/write API defined by FAPI and Open Banking. This includes upgraded cryptography requirements and specifications such as the JWT Secured Authorization Response Mode (JARM) and Client-Initiated Backchannel Authentication (CIBA).

Depending on the flexibility of your chosen OAuth implementation, implementing these specifications will entail varying levels of difficulty. For instance, this would be possible with an extensible library such as IdentityServer4; however, it may be impossible with other implementations.

To act as an ASPSP, you will also need to implement the Financial-grade API (FAPI) itself. This means that you will need to expose your internal systems using the schema defined by FAPI.

If you are AISP or PISP (a client application), you will need to ensure that you can act as an OAuth client application, using the extensions and newer flows required for Open Banking’s security profile. You will also need to integrate with an API that implements FAPI. However, while Open Banking does set standards, you may still encounter some implementation specifics depending on the ASPSP you are integrating with.

Implementing these specifications yourself isn’t as scary as it sounds though, thanks to conformance tools from both the OpenID Foundation and Open Banking.

ID-as-a-Service

Another approach is to use an existing identity provider such as Ping Identity. This involves integrating your existing infrastructure with a third party, who provides the protocol-level support, while you work to build adaptors to integrate with that vendor’s service.

Let’s take a look at how that looks in Ping Identity:

That’s a lot of different products and a lot of places you’re going to have to customize and integrate with. Pricing will vary per vendor, and Open Banking support is typically part of the premium “call us” pricing tier.

There’s also an element of vendor lock-in. Unfortunately, changing vendor is a bit more involved than moving infrastructure from one cloud to another; supporting Open Banking as an ASPSP is no small task. If your vendor decides to renegotiate your contract (they’re known to do this), you will likely need to start from scratch with another vendor.

Using a cloud-based identity provider like this can often be as much effort as doing it yourself. While someone else is now responsible for SLAs and responding to new Open Banking requirements, you have lost a lot of control, and face the risk of doing it all over again.

Trusted Service Providers

An option available to AISPs and PISPs is to use a Trusted Service Provider (TSP). This involves using a third party to handle all of the API communication with the ASPSP. TSPs allow you to integrate with a single set of APIs, with the TSP handling the implementation-specific quirks and Open Banking conformance, significantly lowering the barrier of entry for you to start integrating with banks and bringing your product to market.

The Dangers of Using a SaaS TSP

While using a TSP is a simple solution for getting into Open Banking, be careful what service provider you choose. While they are regulated, in my opinion, Open Banking does allow for TSPs to break the OAuth security model when the TSP is hosted as a Software-as-a-Servie (Saas) solution, running on third party infrastructure.

Let’s think about the OAuth authorization process, where the user is redirected to the authorization server and consents to your application to access their account or to process a payment.

Previously, the user was authorizing your application, but now there is another party involved, one that the user has no knowledge of but who is going to receive the access tokens intended for the AISP/PISP. Not only do they receive and store the tokens for AISP/PISP, but they also broker all of the data between the ASPSP. The user is effectively authorizing the TSP to access their account, not the AISP/PISP.

To integrate the TSP with an ASPSP, you must also share your credentials with the TSP, including client certificates purchased from special EU agencies (see eiDAS). To the ASPS, the TSP is indistinguishable from the AISP/PISP that they think they are integrating with. You have introduced a (presumably) benevolent eavesdropper. This wasn’t acceptable with the OAuth password grant type, and it breaks your OAuth security model.

Yes, there are measures that the TSP can take to prevent token and data theft or misuse, and there are regulations and standards that the TSP must adhere to, but it still breaks the OAuth security model.

I recommend avoiding TSPs offered as SaaS solutions. If you can use a TSP solution that is installable within your own infrastructure, this would be much better, as it is again only your services receiving tokens.

If you must use a SaaS TSP solution, I recommend covering yourself by at least informing the user of the third party during the consent process. For example, as opposed to just “My banking app”, it would be “My banking app via ACME API integrator”.

Conclusion

Open Banking is one of the better implementations of PSD2. It allows for collaboration and for your bank to integrate with other banks or build apps for consumer finance.

It comes with its own set of acronyms and flows, but when you look at it closely, it’s still the OAuth you know and love. As a result, implementing Open Banking yourself isn’t that crazy. While you can use vendors who will implement Open Banking for you, this comes with its own set of business risks and security risks. Most organizations already have an OAuth authorization server or OpenID provider; extending that implementation to meet the Open Banking standards is not out of reach.