Configuration
Authenticating to the Admin API requires an External Application configuration to be created within Banno.
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.
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.
Finally, click the + Create external app button.
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.
Scopes
Enabling specific Scopes, applications will only have access to the parts of the API they’re authorized to use. Scopes enforce the security principle of “least privilege,” meaning that applications are given only the minimum set of scopes required to perform their intended tasks.
More information is available on our General Concepts for Scopes resource page.
Standard application type requirements
The Standard application type provides the ability to “Sign in with Banno” using user-level OAuth.
The following properties are specific to the Standard application type.
Client Type
Authentication can be configured as:
- Confidential, which uses a client secret
User consent required
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.
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/dynamicis NOT the same ashttp://localhost:8080/Dynamicand NOT the same ashttp://localhost:8080/dynamic/. - ‘Wild card’ Redirect URI formats are not allowed, so
https://*.example.comis 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)
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.
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.
JWKS URI
It is an option to provide your public key as a JWKS URI, however there are two requirements:
- JWKS URIs must be accessible via a public-facing web server (ie. the web server must be accessible via the public internet and cannot require a specific network or VPN).
- The JWKS URIs must use https.
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.