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

Requirements (Common)

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.

Requirements (Standard application type)

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

Create external application, standard application type screen

These properties are specific to the Standard application type.

Client Type

Authentication can either be configured as Confidential (which uses a client secret), or Public (which uses PKCE).

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.

Requirements (Service account application type)

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

These 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 Fri Mar 17 2023