Redirect URIs explained
Overview
Akoya uses the OAuth 2.0 framework to enable fintech applications to obtain access via http to end-user data at participating financial institutions.
OAuth 2 puts the end-user in control of the authentication workflow. Authentication starts at the fintech or recipient app (the originating application). Users must grant permission via Akoya directly to their banks' authorization servers before any data is sent back to the application. No user credentials are ever exposed to either Akoya or the application.
After the authentication process is complete, the financial institution sends the end-user back, via Akoya, to the originating application.
The originating application must specify to Akoya where the end-user will return with a redirect URI, also referred to as a callback or a redirection endpoint. See the “Website/Webapp” section of our OAuth implementation guide for more details.
Why registration is important
Because the user’s financial institution is returning sensitive data, you must register at least one redirect URI for your application in the Data Recipient Hub (the Hub). This is a security measure which prevents malicious redirects to rogue servers. Only authorization requests with Akoya-registered redirect URIs are accepted.
After you register your redirect URI(s) in the Hub, you’ll receive a client ID and client secret, which are used for authentication purposes when requesting tokens. The client ID is public information; however it should be protected. The client secret is effectively the password for your application and must be protected.
Requirements
You may use a localhost address with HTTP secure protocol (https://localhost) when testing in our sandbox environment. Otherwise, you should use an externally-accessible address.
You must provide an absolute path for your redirect URI, both when you register it in the Hub and when you include it in your application code.
The redirect URI in your code must be identical to the one registered in the Hub.
See our OAuth guide for more details on implementing OAuth for web, mobile, and desktop.
Resources
Change log
Date | Update |
---|---|
2024-Aug-06 | Added dev help resources. |
2023-Sep-20 | Clarified that HTTPS must be use for localhost in sandbox. |
2022‑Oct‑11 | Original |
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.
Updated about 2 months ago