API Explorer

API Glossary

API.correlation_id

A UUID string generated by OBP-API that MUST uniquely identify the API call recieved by OBP-API. Used for debugging and logging purposes. It is returned in header to the caller.

Example value: 2ba9a7e4-6d02-40e3-a129-0b2bf89de92b

Account

The thing that tokens of value (money) come in and out of. An account has one or more owners which are Users. In the future, Customers may also be owners. An account has a balance in a specified currency and zero or more transactions which are records of successful movements of money.

Account.account_id

An identifier for the account that MUST NOT leak the account number or other identifier nomrally used by the customer or bank staff. It SHOULD be a UUID. It MUST be unique in combination with the BANK_ID. ACCOUNT_ID is used in many URLS so it should be considered public. (We do NOT use account number in URLs since URLs are cached and logged all over the internet.) In local / sandbox mode, ACCOUNT_ID is generated as a UUID and stored in the database. In non sandbox modes (Kafka etc.), ACCOUNT_ID is mapped to core banking account numbers / identifiers at the South Side Adapter level. ACCOUNT_ID is used to link Metadata and Views so it must be persistant and known to the North Side (OBP-API).

Example value: 8ca8a7e4-6d02-40e3-a129-0b2bf89de9f0

Account.account_routing_address

An identifier that conforms to account_routing_scheme / accountRoutingScheme

Example value: DE91 1000 0000 0123 4567 89

Account.account_routing_scheme

The scheme that the account_routing_address / accountRoutingAddress is an example of.

Example value: IBAN

Account.owner

A username that is the owner of the account.

Example value: SusanSmith

Adapter.Kafka.Intro

Brief introduction to using Kafka as the interface layer between OBP and your Core Banking System (CBS).

Prerequesites

  • We assume you have OBP-API running and it is connected to a working Kafka installation. You can check OBP -> Kafka connectivity using the "loopback" endpoint.

  • We assume you have API Explorer running (the application serving this page) but its not necessary - (you could use a REST client)

  • You might want to also run API Manager as it makes it easier to grant yourself roles, but its not nessessary (you could use a REST client / API Explorer instead).
  • You should register a User that you want to use to call the API. Let's call this user Jane.
  • You will need another user that will have the roles required for the following steps. Let's call this user CarolaAdmin.
  • Use Create Auth Context to add a “token” to the User who while request accounts. This token which could be a CUSTOMER_NUMBER is sent inside the AuthInfo object to Kafka
  • OR Use Create Customer and Create User Customer Link (note that Create Auth Context is preferred)

Then its time to configure or program your Adapter to consume, and respond to, the messages OBP will send to Kafka.

We suggest they are implemented in the following order:

1) Core (Prerequisites) - Get Adapter, Get Banks, Get Bank)

2) Get Accounts

3) Get Transactions

4) Manage Counterparties

5) Get Transaction Request Types

  • This is configured using OBP Props - No messages required

6) Get Challenge Threshold (CBS)

7) Make Payment (used by Create Transaction Request)

8) Get Transaction Requests.

9) Generate Security Challenges (CBS)

10) Answer Security Challenges (Validate)

  • Optional / Internal OBP (No additional messages required)

11) Manage Counterparty Metadata

  • Internal OBP (No additional messages required)

12) Get Entitlements

  • Internal OBP (No additional messages required)

13) Manage Roles

  • Internal OBP (No additional messages required)

14) Manage Entitlements

  • Internal OBP (No additional messages required)

15) Manage Views

  • Internal OBP (No additional messages required)

16) Manage Transaction Metadata

  • Internal OBP (No additional messages required)

Adapter.authInfo

authInfo is a JSON object sent by the Connector to the Adapter so the Adapter and/or Core Banking System can identify the User making the call.

The authInfo object contains several optional objects and fields.

Please see the Message Docs for your connector for the current JSON structure. The following serves as a guide:

  • userId is the user_id as generated by OBP
  • username can be chosen explicitly to match an existing customer number (not recommended)
  • linkedCustomers is a list of Customers the User is explicitly linked to. Use the Create User Customer Link endpoint to populate this data.
  • userAuthContexts may contain the customer number or other tokens in order to boot strap the User Customer Links or provide an alternative method of tagging the User with an authorisation context. Use the Create UserAuthContext endpoint to populate this data.
  • cbsToken is a token used by the CBS to identify the user's session. Either generated by the CBS or Gateway.
  • isFirst is a flag that indicates that OBP should refresh the user's list of accounts from the CBS (and flush / invalidate any User's cache)
  • correlationId just identifies the API call.
  • authViews are entitlements given by account holders to third party users e.g. Sam may grant her accountant Jill read only access to her business account. See the Create View endpoint
authinfo_annotated_1

Adapter.cbsToken

A token provided by the Gateway for use by the Core Banking System

Example value: FYIUYF6SUYFSD

Adapter.counterpartyId

The Counterparty ID used in URLs. This SHOULD NOT be a name of a Counterparty.

Example value: 9fg8a7e4-6d02-40e3-a129-0b2bf89de8uh

Adapter.counterpartyName

The name of a Counterparty. Ideally unique for an Account

Example value: John Smith Ltd.

Adapter.customerId

A non human friendly string that identifies the customer and is used in URLs. This SHOULD NOT be the customer number. The combination of customerId and bankId MUST be unique on an OBP instance. customerId SHOULD be unique on an OBP instance. Ideally customerId is a UUID. A mapping between customer number and customer id is kept in OBP.

Example value: 7uy8a7e4-6d02-40e3-a129-0b2bf89de8uh

Adapter.customerNumber

The human friendly customer identifier that MUST uniquely identify the Customer at the Bank ID. Customer Number is NOT used in URLs.

Example value: 5987953

Adapter.iban

MUST uniquely identify the bank account globally.

Example value: DE91 1000 0000 0123 4567 89

Adapter.legalName

The legal name of the Customer.

Example value: Eveline Tripman

Adapter.transactionDescription

A description or reference for the transaction

Example value: For the piano lesson in June 2018 - Invoice No: 68

Adapter.transactionId

The Transaction ID used in URLs. Used to store Metadata for the Transaction.

Example value: 2fg8a7e4-6d02-40e3-a129-0b2bf89de8ub

Adapter.transactionType

A code for the type of transaction

Example value: DEBIT

Adapter.userId

A string that MUST uniquely identify the user on this OBP instance.

Example value: 9ca9a7e4-6d02-40e3-a129-0b2bf89de9b1

Adapter.username

The username the user uses to authenticate.

Example value: felixsmith

Bank

The entity that represents the financial institution or bank within a financial group. Open Bank Project is a multi-bank API. Each bank resource contains basic identifying information such as name, logo and website.

Bank.bank_id

An identifier that uniquely identifies the bank or financial institution on the OBP-API instance.

It is typically a human (developer) friendly string for ease of identification.

It SHOULD NOT contain spaces.

In sandbox mode it typically has the form: "financialinstitutuion.sequencennumber.region.language". e.g. "bnpp-irb.01.it.it"

For production, it's value could be the BIC of the institution.

Example value: GENODEM1GLS

Bank.bank_routing_address

An identifier that conforms to bank_routing_scheme / bankRoutingScheme

Example value: GENODEM1GLS

Bank.bank_routing_scheme

The scheme that the bank_routing_address / bankRoutingAddress is an example of.

Example value: BIC

Branch.branch_id

Uniquely identifies the Branch in combination with the bankId.

Example value: DERBY6

Branch.branch_routing_address

An address that conforms to branch_routing_scheme / branchRoutingScheme

Example value: DERBY6

Branch.branch_routing_scheme

The scheme that the branch_routing_address / branchRoutingAddress is an example of.

Example value: BRANCH-CODE

Consent, or Account onboarding, is the process by which the account owner gives permission for their account(s) to be accessible to the API endpoints.

In OBP, the account, transaction and payment APIs are all guarded by Account Views - with one exception, the account holders endpoint which can be used to bootstrap account on-boarding.

Note: the account holders endpoint is generally made available only to the Account Onboarding App, so if a View does not exist, no API access to the account is possible.

Consent or Account onboarding can be managed in one of two ways:

1) A backend system (CBS or other) is the system of record for User Consent, and OBP mirrors this.

In this case:

a) OBP requires the CBS or other backend system to return a list of accounts and permissions associated with a User.

b) At User login, OBP automatically creates one or more Views for that User based on the permissions supplied by the CBS.

2) OBP is the system of record for User Consent.

In this case:

a) OBP requires the CBS, Gateway or other system to provide just a basic list of accounts owned by the User.

b) The Onboarding App or Bank's Onboarding Page then authenticates the User and calls the Create View endpoint.

c) The account, transaction and payment API endpoints then work as moderated by the relevant View permissions.

d) The User can revoke access by calling the delete View endpoint.

In summary:

Prior to Views being created on an Account for a User, only the 'accounts held' endpoint will work for the account holder, and this endpoint only provides enough information to identify the account so it can be selected and on-boarded into the API.

Once a View exists for an Account, a User can interact with the Account via the API based on permissions defined in the View.

Consumer

The "consumer" of the API, i.e. the web, mobile or serverside "App" that calls on the OBP API on behalf of the end user (or system).

Each Consumer has a consumer key and secrect which allows it to enter into secure communication with the API server.

Customer

The legal entity that has the relationship to the bank. Customers are linked to Users via User Customer Links. Customer attributes include Date of Birth, Customer Number etc.

Customer.customer_id

The identifier that MUST NOT leak the customer number or other identifier nomrally used by the customer or bank staff. It SHOULD be a UUID and MUST be unique in combination with BANK_ID.

Example value: 7uy8a7e4-6d02-40e3-a129-0b2bf89de8uh

Direct Login

Direct Login is a simple authentication process to be used at hackathons and trusted environments:

1) Get your App key

Sign up or login as a developer.

Register your App key HERE

Copy and paste the consumer key for step two below.

2) Authenticate

Using your favorite http client:

POST https://apisandbox.openbankproject.com/my/logins/direct

Body

Leave Empty!

Headers:

Content-Type:  application/json


Authorization: DirectLogin username="janeburel",
                password="the-password-of-jane",
                consumer_key="your-consumer-key-from-step-one"

Here is it all together:

POST https://apisandbox.openbankproject.com/my/logins/direct HTTP/1.1
Authorization: DirectLogin username="janeburel",   password="686876",  consumer_key="GET-YOUR-OWN-API-KEY-FROM-THE-OBP"
Content-Type: application/json
Host: 127.0.0.1:8080
Connection: close
User-Agent: Paw/2.3.3 (Macintosh; OS X/10.11.3) GCDHTTPRequest
Content-Length: 0

You should receive a token:

{"token":"a-long-token-string"}

3) Make authenticated API calls

In subsequent calls you can use the token received in step 2

e.g.

Action:

PUT https://apisandbox.openbankproject.com/obp/v2.0.0/banks/obp-bankx-n/accounts/my-new-account-id

Body:

{  "type":"CURRENT",  "balance":{    "currency":"USD",    "amount":"0"  }}

Headers:

Content-Type:  application/json

Authorization: DirectLogin token="your-token-from-step-2"

Here is another example:

PUT https://apisandbox.openbankproject.com/obp/v2.0.0/banks/enbd-egy--p3/accounts/newaccount1 HTTP/1.1
Authorization: DirectLogin token="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyIiOiIifQ.C8hJZNPDI59OOu78pYs4BWp0YY_21C6r4A9VbgfZLMA"
Content-Type: application/json
Cookie: JSESSIONID=7h1ssu6d7j151u08p37a6tsx1
Host: 127.0.0.1:8080
Connection: close
User-Agent: Paw/2.3.3 (Macintosh; OS X/10.11.3) GCDHTTPRequest
Content-Length: 60

{"type":"CURRENT","balance":{"currency":"USD","amount":"0"}}

More information

Parameter names and values are case sensitive. The following parameters must be sent by the client to the server:

   username
     The name of the user to authenticate.

   password
     The password used to authenticate user. Alphanumeric string.

   consumer_key
     The application identifier. Generated on OBP side via
     https://apisandbox.openbankproject.com/consumer-registration endpoint.

Each parameter MUST NOT appear more than once per request.

Gateway Login

Introduction

Note: Gateway Login is NOT enabled on this instance!

Gateway Login Authorisation is made by including a specific header (see step 3 below) in any OBP REST call.

Note: Gateway Login does not require an explicit POST like Direct Login to create the token.

The Gateway is responsible for creating a token which is trusted by OBP absolutely!

When OBP recieves a token via Gateway Login, OBP creates or gets a user based on the username supplied.

obp login via gateway and jwt

To use Gateway Login:

1) Configure OBP API to accept Gateway Login.

Set up properties in a props file

# -- Gateway login -------------------------------------- # Enable/Disable Gateway communication at all # In case isn't defined default value is false # allow_gateway_login=false # Define comma separated list of allowed IP addresses # gateway.host=127.0.0.1 # Define secret used to validate JWT token # gateway.token_secret=secret # -------------------------------------- Gateway login -- Please keep in mind that property gateway.token_secret is used to validate JWT token to check it is not changed or corrupted during transport.

2) Create / have access to a JWT

HEADER:ALGORITHM & TOKEN TYPE

{ "alg": "HS256", "typ": "JWT" } PAYLOAD:DATA

{ "username": "simonr", "is_first": true, "timestamp": "timestamp", "consumer_id": "123", "consumer_name": "Name of Consumer" } VERIFY SIGNATURE

``` HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload),

) secret base64 encoded

```

Here is the above example token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. AS8D76F7A89S87D6F7A9SD876FA789SD78F6A7S9D78F6AS79DF87A6S7D9F7A6S7D9F78A6SD798F78679D786S789D78F6A7S9D78F6AS79DF876A7S89DF786AS9D87F69AS7D6FN1bWVyIn0. KEuvjv3dmwkOhQ3JJ6dIShK8CG_fd2REApOGn1TRmgU

3) Try a REST call using the header

Using your favorite http client:

GET https://apisandbox.openbankproject.com/obp/v3.0.0/users/current

Body

Leave Empty!

Headers:

   Authorization: GatewayLogin token="your-jwt-from-step-above"

Here is it all together:

GET https://apisandbox.openbankproject.com/obp/v3.0.0/users/current HTTP/1.1 Host: localhost:8080 User-Agent: curl/7.47.0 Accept: / Authorization: GatewayLogin token="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. AS8D76F7A89S87D6F7A9SD876FA789SD78F6A7S9D78F6AS79DF87A6S7D9F7A6S7D9F78A6SD798F78679D786S789D78F6A7S9D78F6AS79DF876A7S89DF786AS9D87F69AS7D6FN1bWVyIn0. KEuvjv3dmwkOhQ3JJ6dIShK8CG_fd2REApOGn1TRmgU"

CURL example

curl -v -H 'Authorization: GatewayLogin token="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. AS8D76F7A89S87D6F7A9SD876FA789SD78F6A7S9D78F6AS79DF87A6S7D9F7A6S7D9F78A6SD798F78679D786S789D78F6A7S9D78F6AS79DF876A7S89DF786AS9D87F69AS7D6FN1bWVyIn0. KEuvjv3dmwkOhQ3JJ6dIShK8CG_fd2REApOGn1TRmgU" https://apisandbox.openbankproject.com/obp/v3.0.0/users/current

You should receive a response like:

{ "user_id": "33fd104f-3e6f-4025-97cc-b76bbdc9148e", "email": "marko@tesobe.com", "provider_id": "marko.milic", "provider": "https://tesobe.openbankproject.com", "username": "marko.milic", "entitlements": { "list": [] } } and custom response header i.e. OBP returns a new token in the custom response header called GatewayLogin (to the Gateway)

{ "username": "simonr", "CBS_auth_token": "fapsoidfuipoi889w3ih", (Encrypted by OBP Adapter) "timestamp": "timestamp", "consumer_id": "123", "consumer_name": "Name of Consumer" } GatewayLogin token="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. AS8D76F7A89S87D6F7A9SD876FA789SD78F6A7S9D78F6AS79DF87A6S7D9F7A6S7D9F78A6SD798F78679D786S789D78F6A7S9D78F6AS79DF876A7S89DF786AS9D87F69AS7D6FN1bWVyIn0. KEuvjv3dmwkOhQ3JJ6dIShK8CG_fd2REApOGn1TRmgU"

Under the hood

The file, GatewayLogin.scala handles the Gateway Login.

We:

-> Check if Props allow_gateway_login is true -> Check if GatewayLogin header exists -> Check if getRemoteIpAddress is OK -> Look for "token" -> If "is_first" is true -OR- CBS_auth_token is empty then, call CBS to get accounts

The CBS_auth_token (either the new one from CBS or existing one from previous token) is returned in the GatewayLogin custom response header.

More information

Parameter names and values are case sensitive.

Each parameter MUST NOT appear more than once per request.

OAuth 1.0a

The following steps will explain how to connect an instance of the Open Bank Project OAuth Server 1.0a. This authentication mechanism is necessary so a third party application can consume the Open Bank project API securely.

The following documentation is based on the OAuth 1.0a specification so if you need more details you can refer to it.

Before starting to interact with the API, third party applications needs to get OAuth keys (consumer key and secret key). You can register your application here to get those keys for interacting with real data. If you want to use the sandbox before handling real data, please register your application here

1) Obtain a request token

To start a sign in flow, the application must obtain a request token by sending a signed message to :

POST https://apisandbox.openbankproject.com/oauth/initiate
  • oauth_callback: an absolute URI back to which the server will redirect the resource owner (user) when Authorization step is completed. If the application is unable to receive callbacks the parameter value MUST be set to “oob” (case sensitive), to indicate an out-of-band configuration.

  • oauth_consumer_key : The identifier portion of the client credentials (consumer key) which is obtained after application registration.

  • oauth_nonce : A nonce is a random string, uniquely generated by the client to allow the server to verify that a request has never been made before. The nonce value MUST be unique across all requests with the same timestamp, application credentials, and token combinations.

  • oauth_signature : the result of signing the request. Explained in detail here.

  • oauth_signature_method : The name of the signature method that will be used by the application to sign the request, as defined in OAuth protocol. The Open Bank Project OAuth server support "SHA1" and "SHA256" so the parameter MUST be set to “HMAC-SHA1" or “HMAC-SHA256”

  • oauth_timestamp : The timestamp value MUST be a positive integer and is expressed in the number of seconds since January 1, 1970 00:00:00 GMT.

  • oauth_version : OPTIONAL. If present, MUST be set to "1.0". Provides the version of the authentication process as defined in the OAuth 1.0 protocol specification.

Example:

POST /oauth/initiate HTTP/1.1

Host: https://apisandbox.openbankproject.com

Authorization: OAuth

oauth_callback="http%3A%2F%2Fprinter.example.com%2Fready",

oauth_consumer_key="cChZNFj6T5R0TigYB9yd1w",

oauth_nonce="ea9ec8429b68d6b77cd5600adbbb0456",

oauth_signature="F1Li3tvehgcraF8DMJ7OyxO4w9Y%3D",

oauth_signature_method="HMAC-SHA256",

oauth_timestamp="1318467427",

oauth_version="1.0"

important: We will explain below in the "signature" section how to calculate the value of the "oauth_signature" field.

Note : line breaks are for display purposes only, the application MUST send the parameters on one line and the only separator between the parameters is a coma “,”.

The server validates the request and replies with a set of temporary credentials in the body of the HTTP response.

Example (line breaks are for display purposes only) :

HTTP/1.1 200 OK
Content-Type: application/x-www-form-urlencoded
oauth_token=hh5s93j4hdidpola&oauth_token_secret=hdhd0244k9j7ao03&oauth_callback_confirmed=true

The application should examine the HTTP status of the response. Any value other than 200 indicates a failure. The body of the response will contain the oauth_token, oauth_token_secret, and oauth_callback_confirmed parameters. The application should verify that oauth_callback_confirmed is true and store the other two values for the next steps.

2) Redirect the user

The next step is to direct the user to Open Bank Project so that he may complete the authentication.

Direct the user to :

GET oauth/authorize

and the request token obtained in step 1 should be passed as the oauth_token parameter.

The most seamless way for a website to implement this would be to issue a HTTP 302 redirect as the response to the original request. Mobile and desktop applications should open a new browser window or direct to the URL via an embedded web view.

Example :

https://apisandbox.openbankproject.com/oauth/authorize?oauth_token=NPcudxy0yU5T3tBzho7iCotZ3cnetKwcTIRlX0iwRl0

Upon a successful authentication, the callback URL would receive a request containing the oauth_token and oauth_verifier parameters. The application should verify that the token matches the request token received in step 1.

If the callback URL was not specified (oob) than the verifier will be shown in the page and the user has to enter it into the application manually.

3) Convert the request token to an access token

To convert the request token into a usable access token, the application must make a:

POST https://apisandbox.openbankproject.com/oauth/token

request containing the oauth_verifier value obtained in step 2. The request token is also passed as oauth_token parameter of the header.

Note : The oauth_callback_url parameter is not necessary any more.

Example :

POST /oauth/token HTTP/1.1

Host: https://apisandbox.openbankproject.com

Authorization: OAuth

oauth_verifier="9312832",

oauth_token=”aze2342352aze”,

oauth_consumer_key="cChZNFj6T5R0TigYB9yd1w",

oauth_nonce="ea9ec8429b68d6b77cd5600adbbb0456",

oauth_signature="F1Li3tvehgcraF8DMJ7OyxO4w9Y%3D",

oauth_signature_method="HMAC-SHA256",

oauth_timestamp="1318467427",

oauth_version="1.0"

Like the step 1, a successful response contains the oauth_token & oauth_token_secret and they should be stored and used for future authenticated requests to the OBP API.

The application can now use the access token to access protected resources.

4) Access protected resources

Once the application has an a access token and secret token, it can access protected resources. The request is the same as in step 3 except the oauth_verifer which MUST not be included in the header.

Please see the API documentation for more details on how to access protected resources.

Recommended OAuth 1.0 libraries:

If you want to use a OAuth library to handle the OAuth process for your application, we have successfully tested these ones:

  • JAVA:

signpost. Warning any version below 1.2.1.2 probably will not work. Version 1.2 which is the current Maven version seems to cause problems.

  • PHP:

OAuth Consumer And Server Library

  • Scala:

Dispatch

  • OBP SDKs / examples of client code with OAuth:

OBP SDKs

Examples :

To show the OAuth integration in concrete examples, please check out these projects listed here: Hello-OBP-OAuth1.0a-LANGUAGE/PLATFORM

Signature :

According to the section-3.4 in the OAuth 1.0 protocol specification the signature computation is done following theses steps :

a) Signature Base String :

The signature base string is a consistent, reproducible concatenation of several of the HTTP request elements into a single string. The string is used as an input to the signature methods.

The signature base string includes the following components of the HTTP request:

  • The HTTP request method (e.g., "GET", "POST", etc.).

  • The authority as declared by the HTTP "Host" request header field.

  • The path and query components of the request resource URI.

  • he protocol parameters excluding the "oauth_signature".

The signature base string does not cover the entire HTTP request. Most notably, it does not include the entity-body in most requests, nor does it include most HTTP entity-headers.

The signature base string is constructed by concatenating together, in order, the following HTTP request elements:

  1. The HTTP request method in uppercase. For example: "HEAD", "GET", "POST", etc. If the request uses a custom HTTP method, it MUST be encoded (Section 3.6).

  2. An "&" character (ASCII code 38).

  3. The base string URI from Section 3.4.1.2, after being encoded (Section 3.6).

  4. An "&" character (ASCII code 38).

  5. The request parameters as normalized in Section 3.4.1.3.2, after being encoded (Section 3.6).

Explained shortly below the example.

Example:

POST /oauth/token HTTP/1.1
Host: https://apisandbox.openbankproject.com
Content-Type: application/x-www-form-urlencoded
Authorization: OAuth
oauth_consumer_key="91919",
oauth_token="OGESD9MrWQEGPXOyPjHCRrCw7BPelWJjnomibV6bePU",
oauth_signature_method="HMAC-SHA256",
oauth_timestamp="1340878170",
oauth_nonce="DFXOQFZVK8K46KDR11",
oauth_signature="bYT5CMsGcbgUdFHObYMEfcx6bsw%3D"

Is represented by the following signature base string (line breaks are for display purposes only):

POST&https%3A%2F%2Fhttps://apisandbox.openbankproject.com&oauth_consumer_key%3D91919%26oauth_nonce%3DDFXOQFZVK8K46KDR11%26oauth_signature_method%3Dhmac-sha256%26oauth_timestamp%3D1340878170%26oauth_token%3DOGESD9MrWQEGPXOyPjHCRrCw7BPelWJjnomibV6bePU%26oauth_verifier%3DT0dXUDBZR09LUVlGTU9NSlhIUUc%26oauth_version%3D1

The request parameters normalization :

  1. The name and value of each parameter are encoded Section 3.6.

  2. The parameters are sorted by name, using ascending byte value ordering.

  3. The name of each parameter is concatenated to its corresponding value using an "=" character (ASCII code 61) as a separator, even if the value is empty.

  4. The sorted name/value pairs are concatenated together into a single string by using an "&" character (ASCII code 38) as separator.

B) Signing the request :

The Open Bank Project OAuth 1.0 implementation uses the “HMAC-SHA1” and “HMAC-SHA256” as signing methods. The key to sign the base string is the concatenation of the consumer secret and the token secret with the “&” character in the middle like this: oauth_consumer_secret&oauth_token_secret, in the first step the application does not have yet a token so it will be an empty string.

The signature that results from the signature process MUST be encoded in base 64 also since the protocol requires encoding all the OAuth parameters.

Illustration of integration with a bank back-end :

The following link shows how the integration of the OAuth process would be with a bank back-end: https://github.com/OpenBankProject/OBP-API/wiki/OAuth-Integration-Illustration

OAuth 2

Note: OAuth2 is NOT allowed on this instance!

OAuth 2 is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service, in this case any OBP REST call. It works by delegating user authentication to the service that hosts the user account, and authorizing third-party applications to access the user account. OAuth 2 provides authorization flows for web and desktop applications, and mobile devices.

OAuth 2 Roles

  • Resource Owner
  • Client
  • Resource Server
  • Authorization Server

Resource Owner: User

The resource owner is the user who authorizes an application to access their account. The application's access to the user's account is limited to the "scope" of the authorization granted (e.g. openid).

Authorization Server: API

The authorization server verifies the identity of the user then issues access tokens to the application. E.g. MITREid Connect

Resource Server: API

The resource server hosts the protected user resources. E.g. OBP-API

Client: Application

The client is the application that wants to access the user's resource. In order to do that, it must be authorized by the user, and the authorization must be validated by the Authorization Server: API.

Authorization Grant

OAuth 2 defines four grant types, each of which is useful in different cases:

  • Authorization Code: used with server-side Applications

  • Implicit: used with Mobile Apps or Web Applications (applications that run on the user's device)

  • Resource Owner Password Credentials: used with trusted Applications, such as those owned by the service itself

  • Client Credentials: used with Applications API access

OBP-API supports at the moment only Authorization Code

Step 1: Get your App key

Sign up or login as a developer

Register your App key HERE

Copy and paste the CONSUMER_KEY, CONSUMER_SECRET and REDIRECT_URL for the subsequent steps below.

Step 2: Authorization Code Link

Using your favorite web browser request a URL like this one

OBP-00010: Missing props value at this API instance - oauth2_server_url/authorize?response_type=code&client_id=CONSUMER_KEY&redirect_uri=REDIRECT_URL&scope=openid

This assumes that that you are already logged in at the OAuth2 authentication server [OBP-00010: Missing props value at this API instance - oauth2_server_url](OBP-00010: Missing props value at this API instance - oauth2_server_url). Otherwise, you will be redirected to [OBP-00010: Missing props value at this API instance - oauth2_server_url/login](OBP-00010: Missing props value at this API instance - oauth2_server_url/login). Please note that you use the same credentials as the sandbox https://apisandbox.openbankproject.com to login to the OAuth2 authentication server.

Here is an explanation of the link components:

  • OBP-00010: Missing props value at this API instance - oauth2_server_url/authorize: the API authorization endpoint

  • client_id=CONSUMER_KEY: the application's client ID (how the API identifies the application)

  • redirect_uri=REDIRECT_URL: where the service redirects the user-agent after an authorization code is granted

  • response_type=code: specifies that your application is requesting an authorization code grant

  • scope=openid: specifies the level of access that the application is requesting

Step 3: User Authorizes Application

Please authorize the application on the OAuth2 server web interface by clicking on "Authorize".

Step 4: Application Receives Authorization Code

If the user clicks "Authorize", the service redirects the user-agent to the application redirect URI, which was specified during the client registration, along with an authorization code.

REDIRECT_URL/&scope=openid/?code=AUTHORIZATION_CODE

The redirect would look something like this: https://YOUR-APPLICATION.com/&scope=openid/?code=h7jSgP

Step 5: Application Requests Access Token

The application requests an access token from the API, by passing the authorization code along with authentication details, including the client secret, to the API token endpoint.

POST OBP-00010: Missing props value at this API instance - oauth2_server_url/token?client_id=CONSUMER_KEY&client_secret=CONSUMER_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URL

Step 6: Application Receives Access Token

If the authorization is valid, the API will send a response containing the access token to the application. The entire response will look something like this:

{
"access_token": "eyJraWQiOiJyc2ExIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJhZG1pbiIsImF6cCI6ImNsaWVudCIsImlzcyI6Imh0dHA6XC9cL2xvY2FsaG9zdDo4MDgwXC9vcGVuaWQtY29ubmVjdC1zZXJ2ZXItd2ViYXBwXC8iLCJleHAiOjE1MTk1MDMxODAsImlhdCI6MTUxOTQ5OTU4MCwianRpIjoiMmFmZjNhNGMtZjY5Zi00ZWM1LWE2MzEtYWUzMGYyYzQ4MjZiIn0.NwlK2EJKutaybB4YyEhuwb231ZNkD-BEwhScadcWWn8PFftjVyjqjD5_BwSiWHHa_QaESNPdZugAnF4I2DxtXmpir_x2fB2ch888AzXw6CgTT482I16m1jpL-2iSlQk1D-ZW6fJ2Qemdi3x2V13Xgt9PBvk5CsUukJ8SSqTPbSNNER9Nq2dlS-qQfg61TzhPkuuXDlmCQ3b8QHgUf6UnCfee1jRaohHQoCvJJJubmUI3dY0Df1ynTodTTZm4J1TV6Wp6ZhsPkQVmdBAUsE5kIFqADaE179lldh86-97bVHGU5a4aTYRRKoTPDltt1NvY5XJrjLCgZH8AEW7mOHz9mw",
"token_type": "Bearer",
"expires_in": 3599,
"scope": "openid"
}

Step 7: Try a REST call using the header

Using your favorite http client:

GET https://apisandbox.openbankproject.com/obp/v3.0.0/users/current

Body

Leave Empty!

Headers:

Authorization: Bearer ACCESS_TOKEN

Here is it all together:

GET /obp/v3.0.0/users/current HTTP/1.1 Host: https://apisandbox.openbankproject.com User-Agent: curl/7.47.0 Accept: / Authorization: Bearer "eyJraWQiOiJyc2ExIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJhZG1pbiIsImF6cCI6ImNsaWVudCIsImlzcyI6Imh0dHA6XC9cL2xvY2FsaG9zdDo4MDgwXC9vcGVuaWQtY29ubmVjdC1zZXJ2ZXItd2ViYXBwXC8iLCJleHAiOjE1MTk1MDMxODAsImlhdCI6MTUxOTQ5OTU4MCwianRpIjoiMmFmZjNhNGMtZjY5Zi00ZWM1LWE2MzEtYWUzMGYyYzQ4MjZiIn0.NwlK2EJKutaybB4YyEhuwb231ZNkD-BEwhScadcWWn8PFftjVyjqjD5_BwSiWHHa_QaESNPdZugAnF4I2DxtXmpir_x2fB2ch888AzXw6CgTT482I16m1jpL-2iSlQk1D-ZW6fJ2Qemdi3x2V13Xgt9PBvk5CsUukJ8SSqTPbSNNER9Nq2dlS-qQfg61TzhPkuuXDlmCQ3b8QHgUf6UnCfee1jRaohHQoCvJJJubmUI3dY0Df1ynTodTTZm4J1TV6Wp6ZhsPkQVmdBAUsE5kIFqADaE179lldh86-97bVHGU5a4aTYRRKoTPDltt1NvY5XJrjLCgZH8AEW7mOHz9mw"

CURL example:

curl -v -H 'Authorization: Bearer eyJraWQiOiJyc2ExIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJhZG1pbiIsImF6cCI6ImNsaWVudCIsImlzcyI6Imh0dHA6XC9cL2xvY2FsaG9zdDo4MDgwXC9vcGVuaWQtY29ubmVjdC1zZXJ2ZXItd2ViYXBwXC8iLCJleHAiOjE1MTk1MDMxODAsImlhdCI6MTUxOTQ5OTU4MCwianRpIjoiMmFmZjNhNGMtZjY5Zi00ZWM1LWE2MzEtYWUzMGYyYzQ4MjZiIn0.NwlK2EJKutaybB4YyEhuwb231ZNkD-BEwhScadcWWn8PFftjVyjqjD5_BwSiWHHa_QaESNPdZugAnF4I2DxtXmpir_x2fB2ch888AzXw6CgTT482I16m1jpL-2iSlQk1D-ZW6fJ2Qemdi3x2V13Xgt9PBvk5CsUukJ8SSqTPbSNNER9Nq2dlS-qQfg61TzhPkuuXDlmCQ3b8QHgUf6UnCfee1jRaohHQoCvJJJubmUI3dY0Df1ynTodTTZm4J1TV6Wp6ZhsPkQVmdBAUsE5kIFqADaE179lldh86-97bVHGU5a4aTYRRKoTPDltt1NvY5XJrjLCgZH8AEW7mOHz9mw' https://apisandbox.openbankproject.com/obp/v3.0.0/users/current

Scenario 1: Onboarding a User

1) Create a user

Action:

POST https://apisandbox.openbankproject.com/obp/v3.0.0/users

Body:

{  "email":"ellie@example.com",  "username":"ellie",  "password":"P@55w0RD123",  "first_name":"Ellie",  "last_name":"Williams"}

Headers:

Content-Type:  application/json

Authorization: DirectLogin token="your-token-from-direct-login"

Please note the user_id

2) Create customer

Requires CanCreateCustomer and CanCreateUserCustomerLink roles

Action:

POST https://apisandbox.openbankproject.com/obp/v3.0.0/banks/BANK_ID/customers

Body:

{  "user_id":"user-id-from-step-1", "customer_number":"687687678", "legal_name":"NONE",  "mobile_phone_number":"+44 07972 444 876", "email":"person@example.com", "face_image":{    "url":"www.openbankproject",    "date":"2013-01-22T00:08:00Z"  },  "date_of_birth":"2013-01-22T00:08:00Z",  "relationship_status":"Single",  "dependants":5,  "dob_of_dependants":["2013-01-22T00:08:00Z"],  "credit_rating":{    "rating":"OBP",    "source":"OBP"  },  "credit_limit":{    "currency":"EUR",    "amount":"10"  },  "highest_education_attained":"Bachelor’s Degree",  "employment_status":"Employed",  "kyc_status":true,  "last_ok_date":"2013-01-22T00:08:00Z"}

Headers:

Content-Type:  application/json

Authorization: DirectLogin token="your-token-from-direct-login"

3) List customers for the user

Action:

GET https://apisandbox.openbankproject.com/obp/v3.0.0/users/current/customers

Body:

Leave empty!

Headers:

Content-Type:  application/json

Authorization: DirectLogin token="your-token-from-direct-login"

4) Create user customer link

Requires CanCreateCustomer and CanCreateUserCustomerLink roles

Action:

POST https://apisandbox.openbankproject.com/obp/v3.0.0/banks/BANK_ID/user_customer_links

Body:

{ "user_customer_link_id":"String", "customer_id":"customer-id-from-step-2", "user_id":"user-id-from-step-1", "date_inserted":"2018-03-22T00:08:00Z", "is_active":true }

Headers:

Content-Type:  application/json

Authorization: DirectLogin token="your-token-from-direct-login"

5) Create account

Requires CanCreateAccount role

Action:

PUT https://apisandbox.openbankproject.com/obp/v3.0.0/banks/BANK_ID/accounts/ACCOUNT_ID

Body:

{  "user_id":"user-id-from-step-1",  "label":"Label",  "type":"CURRENT",  "balance":{    "currency":"EUR",    "amount":"0"  },  "branch_id":"1234",  "account_routing":{    "scheme":"OBP",    "address":"UK123456"  }}

Headers:

Content-Type:  application/json

Authorization: DirectLogin token="your-token-from-direct-login"

6) List accounts

Action:

GET https://apisandbox.openbankproject.com/obp/v3.0.0/my/banks/BANK_ID/accounts/account-id-from-step-2/account

Body:

Leave empty!

Headers:

Content-Type:  application/json

Authorization: DirectLogin token="your-token-from-direct-login"

7) Create card

Requires CanCreateCardsForBank role

Action:

POST https://apisandbox.openbankproject.com/obp/v3.0.0/banks/BANK_ID/cards

Body:

{  "account_id":"account-id-from-step-4","bank_card_number":"String",  "name_on_card":"String",  "issue_number":"String",  "serial_number":"String",  "valid_from_date":"2013-01-22T00:08:00Z",  "expires_date":"2013-01-22T00:08:00Z",  "enabled":true,  "cancelled":true,  "on_hot_list":false,  "technology":"String",  "networks":["String"],  "allows":["credit"],  "account_id":"String",  "replacement":{    "requested_date":"2013-01-22T00:08:00Z",    "reason_requested":"Good Point"  },  "pin_reset":[{    "requested_date":"2013-01-22T00:08:00Z",    "reason_requested":"forgot"  }],  "collected":"2013-01-22T00:08:00Z",  "posted":"2013-01-22T00:08:00Z"}

Headers:

Content-Type:  application/json

Authorization: DirectLogin token="your-token-from-direct0login"

8) List cards

Action:

GET https://apisandbox.openbankproject.com/obp/v3.0.0/cards

Body:

Leave empty!

Headers:

Content-Type:  application/json

Authorization: DirectLogin token="your-token-from-direct0login"

Scenario 2: Create a Public Account

1) Create account

Create an account as described in Step 5 of section Onboarding a user

2) Create a view

Action:

POST https://apisandbox.openbankproject.com/obp/v3.0.0/banks/BANK_ID/accounts/your-account-id-from-step-1/views

Body:

{  "name":"_test", "description":"good", "is_public":true, "which_alias_to_use":"good", "hide_metadata_if_alias_used":false,  "allowed_actions": ["can_see_transaction_this_bank_account", "can_see_transaction_other_bank_account", "can_see_transaction_metadata", "can_see_transaction_label", "can_see_transaction_amount", "can_see_transaction_type", "can_see_transaction_currency", "can_see_transaction_start_date", "can_see_transaction_finish_date", "can_see_transaction_balance", "can_see_comments", "can_see_narrative", "can_see_tags", "can_see_images", "can_see_bank_account_owners", "can_see_bank_account_type", "can_see_bank_account_balance", "can_see_bank_account_currency", "can_see_bank_account_label", "can_see_bank_account_national_identifier", "can_see_bank_account_swift_bic", "can_see_bank_account_iban", "can_see_bank_account_number", "can_see_bank_account_bank_name", "can_see_other_account_national_identifier", "can_see_other_account_swift_bic", "can_see_other_account_iban", "can_see_other_account_bank_name", "can_see_other_account_number", "can_see_other_account_metadata", "can_see_other_account_kind", "can_see_more_info", "can_see_url", "can_see_image_url", "can_see_open_corporates_url", "can_see_corporate_location", "can_see_physical_location", "can_see_public_alias", "can_see_private_alias", "can_add_more_info", "can_add_url", "can_add_image_url", "can_add_open_corporates_url", "can_add_corporate_location", "can_add_physical_location", "can_add_public_alias", "can_add_private_alias", "can_delete_corporate_location", "can_delete_physical_location", "can_edit_narrative", "can_add_comment", "can_delete_comment", "can_add_tag", "can_delete_tag", "can_add_image", "can_delete_image", "can_add_where_tag", "can_see_where_tag", "can_delete_where_tag", "can_create_counterparty", "can_see_bank_routing_scheme", "can_see_bank_routing_address", "can_see_bank_account_routing_scheme", "can_see_bank_account_routing_address", "can_see_other_bank_routing_scheme", "can_see_other_bank_routing_address", "can_see_other_account_routing_scheme", "can_see_other_account_routing_address"]}

Headers:

Content-Type:  application/json

Authorization: DirectLogin token="your-token"

3) Grant user access to view

Action:

POST https://apisandbox.openbankproject.com/obp/v3.0.0/banks/BANK_ID/accounts/your-account-id-from-step-1/permissions/PROVIDER/PROVIDER_ID/views/view-id-from-step-2

Body:

{  "json_string":"{}"}

Headers:

Content-Type:  application/json

Authorization: DirectLogin token="your-token"

Scenario 3: Create counterparty and make payment

1) Create counterparty

Action:

POST https://apisandbox.openbankproject.com/obp/v3.0.0/banks/BANK_ID/accounts/account-id-from-account-creation/VIEW_ID/counterparties

Body:

{  "name":"CounterpartyName",  "description":"My landlord",  "other_account_routing_scheme":"IBAN",  "other_account_routing_address":"7987987-2348987-234234",  "other_account_secondary_routing_scheme":"accountNumber",  "other_account_secondary_routing_address":"BIC201483",  "other_bank_routing_scheme":"bankCode",  "other_bank_routing_address":"10",  "other_branch_routing_scheme":"branchNumber",  "other_branch_routing_address":"10010",  "is_beneficiary":true,  "bespoke":[{    "key":"englishName",    "value":"english Name"  }]}

Headers:

Content-Type:  application/json

Authorization: DirectLogin token="your-token"

2) Make payment by SEPA

Action:

POST https://apisandbox.openbankproject.com/obp/v3.0.0/banks/BANK_ID/accounts/ACCOUNT_ID/VIEW_ID/transaction-request-types/SEPA/transaction-requests

Body:

{  "value":{    "currency":"EUR",    "amount":"10"  },  "to":{    "iban":"123"  },  "description":"This is a SEPA Transaction Request",  "charge_policy":"SHARED"}

Headers:

Content-Type:  application/json

Authorization: DirectLogin token="your-token"        |

3) Make payment by COUNTERPARTY

Action:

POST https://apisandbox.openbankproject.com/obp/v3.0.0/banks/BANK_ID/accounts/ACCOUNT_ID/VIEW_ID/transaction-request-types/COUNTERPARTY/transaction-requests

Body:

{  "to":{    "counterparty_id":"counterparty-id-from-step-1"  },  "value":{    "currency":"EUR",    "amount":"10"  },  "description":"A description for the transaction to the counterparty",  "charge_policy":"SHARED"}

Headers:

Content-Type:  application/json

Authorization: DirectLogin token="your-token"

Scenario 4: Grant account access to another User

1) Create account

Create an account as described in Step 5 of section Onboarding a user

2) Create a view (private)

Action:

POST https://apisandbox.openbankproject.com/obp/v3.0.0/banks/BANK_ID/accounts/your-account-id-from-step-1/views

Body:

{  "name":"_test", "description":"good", "is_public":false, "which_alias_to_use":"accountant", "hide_metadata_if_alias_used":false,  "allowed_actions": ["can_see_transaction_this_bank_account", "can_see_transaction_other_bank_account", "can_see_transaction_metadata", "can_see_transaction_label", "can_see_transaction_amount", "can_see_transaction_type", "can_see_transaction_currency", "can_see_transaction_start_date", "can_see_transaction_finish_date", "can_see_transaction_balance", "can_see_comments", "can_see_narrative", "can_see_tags", "can_see_images", "can_see_bank_account_owners", "can_see_bank_account_type", "can_see_bank_account_balance", "can_see_bank_account_currency", "can_see_bank_account_label", "can_see_bank_account_national_identifier", "can_see_bank_account_swift_bic", "can_see_bank_account_iban", "can_see_bank_account_number", "can_see_bank_account_bank_name", "can_see_other_account_national_identifier", "can_see_other_account_swift_bic", "can_see_other_account_iban", "can_see_other_account_bank_name", "can_see_other_account_number", "can_see_other_account_metadata", "can_see_other_account_kind", "can_see_more_info", "can_see_url", "can_see_image_url", "can_see_open_corporates_url", "can_see_corporate_location", "can_see_physical_location", "can_see_public_alias", "can_see_private_alias", "can_add_more_info", "can_add_url", "can_add_image_url", "can_add_open_corporates_url", "can_add_corporate_location", "can_add_physical_location", "can_add_public_alias", "can_add_private_alias", "can_delete_corporate_location", "can_delete_physical_location", "can_edit_narrative", "can_add_comment", "can_delete_comment", "can_add_tag", "can_delete_tag", "can_add_image", "can_delete_image", "can_add_where_tag", "can_see_where_tag", "can_delete_where_tag", "can_create_counterparty", "can_see_bank_routing_scheme", "can_see_bank_routing_address", "can_see_bank_account_routing_scheme", "can_see_bank_account_routing_address", "can_see_other_bank_routing_scheme", "can_see_other_bank_routing_address", "can_see_other_account_routing_scheme", "can_see_other_account_routing_address"]}

Headers:

Content-Type:  application/json

Authorization: DirectLogin token="your-token"

3) Grant user access to view

Action:

POST https://apisandbox.openbankproject.com/obp/v3.0.0/banks/BANK_ID/accounts/your-account-id-from-step-1/permissions/PROVIDER/PROVIDER_ID/views/view-id-from-step-2

Body:

{  "json_string":"{}"}

Headers:

Content-Type:  application/json

Authorization: DirectLogin token="your-token"

Transaction

Records of successful movements of money from / to an Account. OBP Transactions don't contain any "draft" or "pending" Transactions. (see Transaction Requests). Transactions contain infomration including type, description, from, to, currency, amount and new balance information.

Transaction Requests

Transaction Requests are records of transaction / payment requests coming to the API. They may or may not result in Transactions (following authorisation, security challenges and sufficient funds etc.)

A successful Transaction Request results in a Transaction.

For more information see here

Transaction Requests.Transaction Request Type

The Transaction Request Type defines the request body that is required - and the logic / flow of the Transaction Request. Allowed values include SEPA, COUNTERPARTY and SANDBOX_TAN.

Example value: SEPA

User

The entity that accesses the API with a login / authorisation token and has access to zero or more resources on the OBP API. The User is linked to the core banking user / customer at the South Side Adapter layer.

Link Users and Customers in a many to many relationship. A User can represent many Customers (e.g. the bank may have several Customer records for the same individual or a dependant). In this way Customers can easily be attached / detached from Users.

User.provider

The name of the authentication service. e.g. the OBP hostname or kafka if users are authenticated over Kafka.

User.provider_id

The id of the user given by the authenticaiton provider.

User.user_id

An identifier that MUST NOT leak the user name or other identifier nomrally used by the customer or bank staff. It SHOULD be a UUID and MUST be unique on the OBP instance.

Example value: 9ca9a7e4-6d02-40e3-a129-0b2bf89de9b1