REST OAuth Information

Overview

jXchange (JX) REST, has focused on secure, reliable performance. We’re now enhancing jXchange-REST security by strengthening the OAuth 2.0 (RFC 6749: The OAuth 2.0 Authorization Framework) used from Client Id and Secret to using PEM keys, ensuring alignment with modern cloud security standards. This improvement reflects our dedication to maintaining the highest security standards and proactively safeguarding our systems.

Why are we making this change?

OAuth 2.0 offers a more robust, secure, and modern solution with features such as:

• Token-based authentication: Short-lived access tokens that can be easily revoked, minimizing the impact of compromised credentials.
• Delegated authorization: Securely grant access to third-party applications without sharing sensitive user credentials.
• Improved observability: Institutions can self-manage and review API clients in an administrative portal.

What are the benefits?

This upgrade will significantly enhance the security posture of our APIs, protecting sensitive data. Additionally, it will:

• Standardize the authentication model across SOAP and REST services
• Reduce the risk of credential theft and unauthorized access.
• Ensure compliance with industry best practices and regulatory requirements.
• Eliminates the need for Internet Protocol (IP) address filtering.

When are these changes taking place?

• October 31, 2026: New configurations for the legacy ClientID/Secret authentication model will be no longer be accepted. All new JX API Gateway configurations after 10/31/2026 will only be accepted with the OAuth 2.0 with signed private key jwt.

What are the changes?

This security model will require changes for all current jXchange-REST consumers and FIs. At a high level, consumers will need to migrate from the older ClientId/Secret Model to the new OAuth 2.0 confidential client credential. That means:

• Client Id and Secret are no longer used to access the jXchange-REST APIs.
• To establish an OAuth client, the API consumer must create a private and public key pair (Public Key + Private Key | Digital Toolkit | Jack Henry Docs).
• Initial Configuration:
  • Institutions will have administrative oversight to manage the consumers who access their data.
  • Consumers will provide the public key in PEM format or a JWKS URL to the institution to create their API client.
  • Institutions will provide the client id to the consumer.
  • Consumers will follow the OAuth 2.0 client credential flow with signed JWT to access API resources
    • Scopes required in the token request include: https://jackhenry.com/jx/jxapigateway.write
• New jConnect egress IP addresses: 216.116.94.254
• New jXchange endpoint: https://jx-apigtw.jackhenry.com/jx-api

Next Steps

The expectation is for consumers to understand the OAuth 2.0 process before consuming our APIs.

We recommend that you review the Getting Started OAuth 2.0 Authentication page for more detailed information about this change. Please read the information and any referenced sites thoroughly before beginning development.

Once testing with the OAuth credentials is complete, an Integration Readiness Check is required before the new enhanced credentials may be requested in any bank environment. Please refer to the following pages for more information:

• Fintech Integration Phases: Phase 4-Integration Readiness Check
• Fintech jXchange Requirements and Readiness

Contacting Jack Henry

• Vendor Integration Program Members: Please open a support case through the Vendor Portal and provide your newly created public key or JWKS URL and a listing of all APIs that your solution is consuming.
• Fintech Integration Network Members: Please send an email to Developer Relations and provide your newly created public key or JWKS URL and a listing of all APIs that your solution is consuming.
• Financial Institutions: Contact Vendor QA for assistance.
• For community support and general questions, visit Stack Overflow.