How-tos

5 mins read

Security and OAuth for Open Finance - Quickstart with Demo

Leverage Cloudentity's FAPI-grade authorization server to build an Open Finance/Data ecosystem. Use built-in demo to explore how an external consent storage can be built and utilized to store user's consent. Enable TPPs to request authorized access to your users' data.

Generic Open Banking Quickstart

Generic Open Banking Quickstart enables financial institutions building Open Finance/Data ecosystems to leverage Cloudentity as an information security provider. This way, the institutions can focus on what matters the most - building data models, consent profiles, and providing satisfactory user journeys.

The Generic Open Banking workspace profile complies out-of-the-box with Financial-Grade API (FAPI) requirements, but can be configured to any institution’s needs.

Security and OAuth for Open Finance Ecosystems - Demo

Cloudentity Generic Open Banking workspace profile has a built-in demo that we will explore to:

  1. Create a FAPI-Grade authorization server.

  2. Spin up a dockerized and local Open Finance environment with:

    • A mock third-party provider application (Financroo)

    • Mock financial institutions (Hyperscale Bank and Go Bank)

    • A mock Consent Storage service.

Prerequisites

Get FAPI-Grade Authorization Server for Open Finance

  1. Create a workspace.

  2. Choose the TRY THE DEMO button next to the Generic Open Banking workspace profile.

Generic Open Finance authorization server

For your conveniance, we create two workspaces:

  • Go Bank Demo workspace

  • Hyperscale Bank Demo workspace

Get Open Finance Sandbox Environment

  1. Select Quickstart in the Go Bank Demo workspace.

  2. Follow the instructions from the quickstart page.

    1. Download a preconfigured package or clone the Open Banking Quickstart repository and follow the readme.

      git clone git@github.com:cloudentity/openbanking-quickstart.git

    2. Run the mock applications.

      docker-compose pull
docker-compose up

Application Access

Once the applications are deployed and running, you can access the following components at below mentioned URLs.

  • Financroo TPP: https://localhost:8091/
  • External Consent Storage Mock: https://localhost:8084

In your Go Bank Demo Workspace, navigate to Applications » Clients. You can see that we preconfigured some clients for you:

  • Consent Page Bank Client (mock consent page for the Go Bank)

  • Financroo TPP - dynamically registered client application that for the TPP. See next section for details.

  • User portal - for users to manage their consent.

  • Bank’s client

TPP Registration

In generic Open Banking quickstart package Financroo TPP is configured to connect to two mock banks:

  • Go Bank
  • Hyperscale Bank

Each of the bank is represented by a separate authorization server.

Here’s the Financroo bank’s configuration:

{
 "banks": [
  {
   "acp_internal_url": "https://{tenant-id}.mtls.{region-id}.authz.cloudentity.io",
   "acp_url": "https://{tenant-id}.{region-id}.authz.cloudentity.io",
   "enable_dcr": true,
   "id": "gobank",
   "name": "Go Bank",
   "server": "fapi_20_security-demo-f-re5eu7wt",
   "tenant": "obgeneric",
   "url": "http://gobank:8070"
  },
  {
   "acp_internal_url": "https://{tenant-id}.mtls.{region-id}.authz.cloudentity.io",
   "acp_url": "https://{tenant-id}.{region-id}.authz.cloudentity.io",
   "enable_dcr": true,
   "id": "hyperscalebank",
   "name": "Hyperscale Bank",
   "server": "hyperscalebank-ssis_mzpqx",
   "tenant": "obgeneric",
   "url": "http://hyperscalebank:8070"
  }
 ]
}

By default, Financroo is configured to use Dynamic Client Registration enable_dcr to enroll to given authorization server.

Once you run the Financroo TPP, it registers a client on startup once.

Financroo TPP is using the OAuth authorization code flow with Proof Key of Code Exchange (PKCE) and Pushed Authorization Requests (PAR) to request the accounts scope.

After initial call to PAR endpoint, the user is redirected to the authorization server to log in.

By default, we have configured a mock identity provider in Cloudentity, so the user can login. (use user/p@ssword! as credentials).

Once authenticated, the Cloudentity platform serves the consent application to the user. Consent application is served based on the Cloudentity authorization server setting.

Once user consents to the application, Cloudentity platform issues relevant authorization code back to Financroo TPP.

Financroo TPP exchanges the code to access, ID and, optionally, refresh token, and as the result, the TPP can fetch Consumer data from the Bank.

Protecting Bank API’s

In our sandbox, the TPP is calling the Bank’s APIs by passing an opaque accessToken string.

To protect Bank API’s OAuth2 Introspection endpoint can be used to check:

  • If the access token is still active.
  • What is the consent ID.
  • What scopes has been granted.

The sandbox gives only a basic level of your bank’s API protection.

Cloudentity provides the possibility to integrate API Gateways and Service Meshes into its authorization platform in order to secure them with policies. To that end, it uses authorizers - system components responsible for discovering APIs and Services and synchronizing policies with those APIs and Services.

Add multi-dimensional authorization to your Financial Institution’s Data and Consent APIs using financial-grade OAuth server, distributed API declarative authorization solutions, and Policy-Based Access Control. Empower users to authorize individual transactions. Add fine-grained consent enabling customers to authorize third-party access to discrete resources. Utilize rich authorization request to make scope of access granular.

Learn more.

As part of the Sanbox, you can see how we mocked an Consent Storage systems to enable your users to review and manage their consents at any given point.

The Go Bank has a built-in a Mock Consent Storage available under the https://localhost:8084 URL. You can use it to review and revoke consents. Note that the consent status changes to revoked once the consent is revoked.

To be able to revoke an access token after you revoke consent, check the Logs in the System workspace for your tenant for the consent identifier. If you do not have access to the system tenant, contact Cloudentity sales team.

The Hyperscale Bank uses an external consent service we mocked using Cloudentity Identity Pools, typically used to store users at hyper-scale, but this time used as a consent data store.

We modified the pool’s (consent’s) Identity Schema to store consent attributes.

Mocked Consent Model

You can find all consent issued in Identity Pools » Hyperscale Bank Consent Storage » Users.

External Consent Storage

For revoking a particular access token associated with the given consent, you can find the consent identifier in the given consent’s object User ID.

The following System API can be used to revoke tokens (both access and refresh token) assosiated with a given consent.

Cleanup

If you want to clean up all the locally deployed resources, use the following command:

make clean
Updated: Nov 2, 2023