Configuration

Consumer API > Overview > 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.

Understanding Your Development Experience

Are you a financial institution?

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.

Are you a fintech or independent developer?

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.

Consumer API - Setup a new external application

Requirements

Name

The Name field specifies the name of the External Application.

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.

Order of Redirect URIs

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.

Exact String Matching of Redirect URIs

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.

Secure Redirect URIs

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.

If you are developing using a Jack Henry test environment, you will not have access to Banno People. In this case, Jack Henry is the acting administrator of the financial institution and you will have to contact us for any Banno People operations.

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.

Have a Question?

Have a how-to question? Seeing a weird error? Get help on StackOverflow.

Register for the Digital Toolkit Meetup where we answer technical Q&A from the audience.

Last updated Thu Aug 29 2024