Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
OAuth 1.0 Server
- OAuth flow
- Recommended OAuth 1.0 libraries
- Integration Example
See and use our OAuth SDKs and examples
The following steps will explain how to connect an instance of the Open Bank Project OAuth Server 1.0a. You may well want to use a different host. 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
The BASE-URL alias in the following URLs must be replaced by https://api.openbankproject.com or https://apisandbox.openbankproject.com depending if you are accessing the real data or the sandbox.
Step 1 : Obtaining a request token :
To start a sign in flow, the application must obtain a request token by sending a signed message to :
POST BASE-URL/oauth/initiate with the following parameters :
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.
POST /oauth/initiate HTTP/1.1
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
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.
Step 2 : Redirecting 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.
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.
Step 3 : Converting the request token to an access token
To convert the request token into a usable access token, the application must make a:
POST BASE-URL/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.
POST /oauth/token HTTP/1.1
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.
Step 4 : Accessing 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:
- signpost. Warning any version below 18.104.22.168 probably will not work. Version 1.2 which is the current Maven version seems to cause problems.
OBP SDKs / examples of client code with OAuth:
To show the OAuth integration in concrete examples, please check out these projects listed here:
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.
- The 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:
- 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).
- An "&" character (ASCII code 38).
- The base string URI from Section 22.214.171.124, after being encoded (Section 3.6).
- An "&" character (ASCII code 38).
- The request parameters as normalized in Section 126.96.36.199.2, after being encoded (Section 3.6).
Explained shortly below the example.
POST /oauth/token HTTP/1.1
Is represented by the following signature base string (line breaks are for display purposes only):
The request parameters normalization :
- The name and value of each parameter are encoded Section 3.6.
- The parameters are sorted by name, using ascending byte value ordering.
- 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.
- 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