Configuration
Authenticating to the Consumer API requires an External Application configuration to be created within Banno.
The back office administrator at your financial institution can do this for you in Banno People.
If the back office administrator does not know where to do this, they can review the External application configuration article on the Banno Knowledge site.
If you are a financial institution or working directly with a financial institution, you should work with the back office administrator at your institution to get appropriate access to Banno People.
If you are a fintech or other developer working without a financial institution, you are likely using the JackHenry.Dev developer portal. In this case, you will not have access to Banno People, however you will still have the ability to create and configure many aspects of your external application and plugin.
For more information on this, see our troubleshooting page.
Requirements
Name
The Name field specifies the name of the External Application.
Client Type
The Client Type field supports two values:
- Confidential
- This client type requires both a Client ID and a Client Secret for authentication to the token endpoint.
- This is the recommended option for clients which can keep secrets secure, i.e. backend services.
- Public
- This client type uses only a Client ID for authentication, but requires the use of Proof Key for Code Exchange (PKCE).
- This should only be used for clients which cannot keep secrets secure, i.e. native mobile apps or OAuth performed from JavaScript in a single page application.
User consent required
This option determines whether or not a user will see the Consent Experience as described in the Permissions Flow.
Trusted integrations (full vendor partners) should not require the user to give consent. Third party integrations should prompt the user to provide consent.
Redirect URIs
These are the Redirect URIs that the Consumer API uses to return users to your client as part of the Authorization Code Flow.
- For generic usage of the Consumer API, the order of the Redirect URIs is not important.
- In the specific context of using an External Application as a part of a Plugin, the order becomes important. See the Plugins - External Applications topic for more details.
Each Redirect URI is matched using exact string matching. If the Redirect URI does not match, then the authorization flow will not be valid.
- Redirect URI matching is case-sensitive and path-inclusive so http://localhost:8080/dynamic is NOT the same as http://localhost:8080/Dynamic and NOT the same as http://localhost:8080/dynamic/.
- ‘Wild card’ Redirect URI formats are not allowed so https://*.example.com is NOT valid.
Redirect URIs must use HTTPS except in local development. HTTPS is required for all production redirect URIs to properly secure the connection between your application and our API.
The only exception is for local development. The following is a list of local options which are included in the HTTP allowlist:
- Host names of localhost or those that end in .local
- Any address in the IPv4 range of 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 (which includes http://127.0.0.1)
Claims
The Restricted Claims contain potentially sensitive data about the user. To request and obtain these claims, the External Application must be specifically configured to allow them. See the Authentication Framework - OpenID Connect and OAuth 2.0 topic for more details.
The back office administrator at your financial institution can do this for you in the External applications section of Banno People.
Output
Client ID
This is the Client ID that you’ll use in the Authorization Code Flow.
See the Authentication topic.
Client Secret
This is the Client Secret that you’ll use in the Authorization Code Flow.
See the Authentication topic.