Account linking and consent use case

Traditional account linking and consent flow depends on credential-based screen scraping. This process is heavily reliant on consumer credentials, which can lead to issues with data security, negative user experiences, and high website traffic. Scraped data is also less reliable and prone to errors.

Akoya offers a better solution. It provides an API-only, permissioned-driven open finance network that overcomes the inherent problems of screen scraping.

From a customer viewpoint, the process to link an account and give consent through Akoya is simple. The new app routes the user to their existing bank portal. The user completes the normal authentication process and consents to link the account.

The process for a developer begins with the consent flow. This enables a customer to authenticate, select accounts, and permission data to flow from their data provider through the Data Access Network and to a third-party fintech app. This keeps your customers’ sign in credentials from being shared with third parties.

After authentication and authorization, Akoya returns the end-user to your redirect URI with an authorization grant code in the URL. This use case procedure began after you receive that authorization grant code.

For more information, see the blog post A Consumer-First Approach to Account Linking.

Prerequisites

The API calls require you to have joined the Data Recipient Hub and set up your app to work with the Akoya Data Access Network (DAN). For more information on these processes, refer to these resources:

Find the authorization code

Akoya returns the end-user to your redirect URI with an authorization grant code in the URL. code= precedes the grant code. The code fogeqqbz2xi23hvgvlu4ka2kq is shown in the example. For more information, see Get authorization code.

Callback success example

https://example-app.com/callback?code=fogeqqbz2xi23hvgvlu4ka2kq&state=123abc

Exchange the code for an ID and refresh token

The token endpoint response returns an id_token and a refresh_token. The id_token is the bearer token used for data calls. Use the refresh_token retrieves a new set of tokens. For more information, see Tokens.

Make the GET request /token for an id token.

Set the grant_type to authorization_code.
The redirect_uri is the URI where user will be redirected after end-users authorization is complete.
The code is the authorization grant code retrieved in step 1.

Exchange code for tokens curl example

curl --request POST  
     --url https://sandbox-idp.ddp.akoya.com/token  
     --header 'accept: application/json'  
     --header 'content-type: application/x-www-form-urlencoded'  
     --data grant_type=authorization_code  
     --data redirect_uri=<https://recipient.ddp.akoya.com/flow/callback>  
     --data 'code=<authorization-code>'\`

Find and copy the token strings

The API response contains the id_token and refresh_token strings. Copy and store these values in a safe place. Use your current secure token storage or implement a way to store each end-user's unique tokens.

Token results example

{
  "expires_in": 86399,
  "id_token": "<id-token>
  "refresh_token": "<refresh-token",
  "scope": "openid offline_access",
  "token_type": "bearer"
}

Refresh tokens

Repeat your get request on the token endpoint with different parameters to obtain a new set of tokens. The refresh token expiration is set by the data provider.

Make the GET request /token to refresh tokens.

Set the grant_type to refresh_token.
The refresh_token is in the results from the tokens call in step 1.
The client_id is your app’s client ID from Akoya
The client_secret is your app’s client secret from Akoya

You can find the client_id and client_secret under the My app tab of the Akoya Data Recipient Hub .

Refresh tokens curl example

curl --request POST \
     --url https://sandbox-idp.ddp.akoya.com/token \
     --header 'accept: application/json' \
     --header 'content-type: application/x-www-form-urlencoded' \
     --data grant_type=refresh_token \
     --data 'refresh_token=<refresh-token>' \
     --data 'client_id=<client-id>' \
     --data 'client_secret=<client-secret>'

The refresh tokens result is the same format as the token results example.

Need help?

Check out our Developer Community, or visit the Support Center in the Data Recipient Hub.

Looking for provider nuance documentation?

All provider nuance documentation is available in the Data providers section in the Data Recipient Hub.

Still stuck?

For all production issues, submit a support ticket through the Data Recipient Hub. Our support team is standing by 24/7. Questions and non-production issues will be answered during business hours.