Client Creds Flow

Quickstart

Quickstarts are designed to help get you up and running fast.

After completing a Quickstart, continue your learning journey by diving into the API Reference and other guidance within this Jack Henry Identity site.

Try our Authentication - Client Credentials (Command Line) quickstart.

Note, the Client Credentials Code Flow Quickstart is contained within the Banno Admin API portion of the site. That’s because the authentication framework was initially developed for use with our Banno Admin and Consumer API’s. We’ve extended and enhanced the functionality to support all of Jack Henry, and are working to get documentation updated across the interconnected parts of jackhenry.dev.

Decisions / Need to Knows About Your Approach

1. What scopes do you need, and how will they be enforced?
2. How will you securely handle the private key(s)?
3. Will you provide your public key as a JWKS URI or in PEM format?

A signed client assertion JWT is passed to the OpenID provider, which only has access to the public key. It’s critical that the private key be handled securely and kept private.

This approach reduces the risk of a client secret being intercepted, and an attacker impersonating the client.

If you intend to rotate public keys, then a JWKS URI is required so you can rotate without downtime, and without Jack Henry Identity operational teams needing to be involved. Jack Henry will only support rotation of keys for cause, rather than on a fixed interval.

Scopes

If you’re new to working with scopes, start by reviewing the general concept.

Scopes define the categories of data that can be accessed and the operations that can be performed. In general, scopes are less granular than permissions and a single scope may cover multiple API’s.

Example

Let’s pretend the following API’s need to be supported:

• GET /{InstitutionUniversalId}/enterprise/{EnterpriseUserId}/accounts/{Id}
• GET /{InstitutionUniversalId}/enterprise/{EnterpriseUserId}/accounts/{Id}/account-summary
• GET /{InstitutionUniversalId}/enterprise/{EnterpriseUserId}/accounts/{Id}/available-balance
• POST {InstitutionUniversalId}/enterprise/{EnterpriseUserId}/accounts/inquiry
• PUT {InstitutionUniversalId}/enterprise/{EnterpriseUserId}/accounts/{Id}
• PATCH {InstitutionUniversalId}/enterprise/{EnterpriseUserId}/accounts/{Id}/dates
• PATCH {InstitutionUniversalId}/enterprise/{EnterpriseUserId}/accounts/{Id}

For these API’s it likely makes sense to support the following scopes:

• accounts.read
  • GET /{InstitutionUniversalId}/enterprise/{EnterpriseUserId}/accounts/{Id}
  • GET /{InstitutionUniversalId}/enterprise/{EnterpriseUserId}/accounts/{Id}/account-summary
  • GET /{InstitutionUniversalId}/enterprise/{EnterpriseUserId}/accounts/{Id}/available-balance POST {InstitutionUniversalId}/enterprise/{EnterpriseUserId}/accounts/inquiry
• accounts.write
  • PUT {InstitutionUniversalId}/enterprise/{EnterpriseUserId}/accounts/{Id}
  • PATCH {InstitutionUniversalId}/enterprise/{EnterpriseUserId}/accounts/{Id}/dates
  • PATCH {InstitutionUniversalId}/enterprise/{EnterpriseUserId}/accounts/{Id}

Remember, the scopes apply to the OAuth client (i.e. external application), not the {EnterpriseUserId}.

The {EnterpriseUserId} in the API request path likely also needs to have some permissions. In many (but not necessarily all) cases, those permissions will be more granular than the scopes.

Additional resources to support the implementation for Jack Henry product teams are available from the Developer Relations group.