Authentication Framework

This Authentication Framework applies to all API consumers using the Enterprise REST APIs.

The purpose of the Authentication Framework is to protect user data using industry standards like OAuth 2.0 and OpenID Connect, which provide authenticated information in the form of secure access and identity tokens.

The Jack Henry Enterprise Rest API specification defines authentication as a process by which a user or service is securely identified through the exchange of identity material (username/password, secret key, digital certificate, etc.) with an identity provider from which a security token is generated that an API service can receive, inspect, and understand the owner/subject of the token (caller).

For instance, every service/API should require the caller to supply a security token in which the service can inspect the caller identity and metadata for determining if the work requested should be performed.

Authentication Architecture

The Authentication Framework is based on the industry standard OAuth 2.0 and OpenID Connect architecture.

In this architecture, the User is considered to be the Resource Owner (in this case, the owner of their identity, data, and operations). The User is a separate entity from the Client.

The Client (aka 3rd party app) is considered to be the Relying Party as it is relying upon an Authorization Server to authenticate a User.

The Authorization Server is an Identity Provider that authenticates the User. The User can tell the Authorization Server to provide the Client with authorized access to resources that the User owns.

Once authorized, the Authorization Server provides an Access Token and an Identity Token to the Client.

The Identity Token provides authenticated information about the User to the Client. The Client uses the Access Token to gain access to the User resources that are held on the Resource Server.

Security Token Details

For the Jack Henry Enterprise APIs, the security token format will be a JSON Web Token (JWT), which is a coded and signed compilation of JSON documents, and in the form of a ‘value’ token (that is generated by an OpenID Connect token provider.

The JWT (pronounced ‘jot’) will be used as a mode of trust between the caller, the token server, and the relying party (service).

JWTs also can be passed as part of a request payload as needed to identify entities other than the caller in an ‘on behalf of’ transaction.

Since Jack Henry Enterprise callers are traditionally other services and not people, the token sent to access the service will not always be the token of the ‘person at keyboard’ (PAK).

This behavior and identity flow are almost identical to the current SAML identity flow used in the current JH SOAP API implementation.

JSON Web Token Details

API services should authenticate (validate tokens) on every call to support/promote scalability.

To also reduce the reliance on sessions, internal services (beyond the initial validating service) can implement shared-keys or other high-performing microservice authorization practices to reduce token validation activity on internal microservice communication hops.

Services will also be required to inspect the JWT for components related to both authentication (identification) and authorization. The JWT will contain, for product tokens, values of Consumer Name (ConsumerName) and Consumer Product (ConsumerProduct). Moving this data into the JWT ensures the information cannot be tampered.

Authorization

The standard OAuth 2.0 authorization framework is not directly considered in this implementation.

The identity of the caller is paramount to the authorization of the caller to the service in question.

The Enterprise REST API services will maintain the authorization status of the caller (or type of caller) as appropriate for their system based on the validated JWT sent with the API call.

In certain instances, the tokens for a caller (a service) and the PAK (someone at a user interface) may both be inspected to determine the appropriate actions to be taken.

Unlike OAuth 2.0 access tokens, the OpenID Connect JWT supplied as identity will contain specific information that can be used by a service for authorization even in the case where the service is remote from the initial API endpoint.

Authentication example

jhaOIDCScheme

Token must be an OIDC jwt, e.g. jwt< GeneratedOidcJwt >

bearerAuth