Digital Toolkit

Configuration

Admin API > Overview > Configuration

Authenticating to the Admin API requires an External Application configuration to be created within Banno.

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 the Admin API.

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 the Banno Back Office.

The back office administrator at your financial institution can do this for you in the Users & Groups section of Banno.

From the Banno People dashboard, click the ... button to open the menu and select Users & Groups.

Users & Groups Menu

Finally, click the + Create external app button.

Create external application screen

Common requirements

These properties are common to both the Standard application type and Service account application type.

Name

The name of the External Application.

Partner Name

The name we use to monitor and track integrators using the Admin API.

Application Type

There are two different application types: standard and service account.

Standard application type requirements

The Standard application type provides the ability to “Sign in with Banno” using user-level OAuth.

Create external application, standard application type screen

The following properties are specific to the Standard application type.

Client Type

Authentication can either be configured as:

This option determines whether or not a user will see a consent prompt during authentication.

User consent should be required unless the application is owned by the institution or a fully trusted partner.

Redirect URIs

These are the Redirect URIs that the Admin API uses to return users to your client as part of the Authorization Code Flow for the Standard application type.

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)

Service account application type requirements

The Service account application type uses a signed JWT for authentication.

A service account provides application-level authentication instead of user-level authentication.

Create external application, service account application type screen

The following properties are specific to the Service account application type.

Client Type

Authentication for Service accounts uses a Signed JWT.

Public Key

See the Public Key + Private Key topic.

Associated User

See the Associated User topic.

Client ID

Both the Standard application type and Service account application type will generate a Client ID when the External Application is created.

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 Wed Oct 25 2023