Skip to main content

Authentication - how bank clients prove identity to AIS

Bank integrations must follow your security standards (vaults, key rotation, mTLS at the edge, IP allow lists). This page explains what kinds of credentials AIS Pro Gateway is designed around, in conceptual terms only.

JWT bearer sessions (typical for apps and interactive flows)​

The common pattern is:

  1. Authenticate with a login request that identifies a service account or user (exact payload and policies are deployment-specific).
  2. Receive a short-lived access token and a longer-lived refresh token (when refresh is enabled).
  3. Send Authorization: Bearer <access_token> on protected API calls until the access token expires.
  4. Refresh before expiry using the refresh token, or re-authenticate if refresh fails.

This is the same OAuth2-style mental model many banks already use (“get a bearer token, send it on each call”), even when the token issuer is AIS’s gateway rather than your corporate IdP. Federation (OIDC / SSO in front of AIS) may exist in your program-confirm with AIS.

Practices your security team will expect:

  • Store tokens in vaults or HSM-backed secret stores, not in tickets or shared documents.
  • Prefer short-lived access tokens and single refresh attempts on 401.
  • Log correlation_id from error responses when opening incidents-not raw tokens.

API keys (optional server-to-server)​

When your deployment enables it, machine-to-machine calls may use an X-API-Key (or equivalent) header instead of or alongside a bearer token. Keys are created and rotated by administrators; permissions follow the role attached to the key.

  • If both Bearer and API key are sent, precedence can be deployment-specific-confirm during integration testing.
  • Rotate keys on a schedule and after staff changes, using the process AIS documents for operators.

What this page deliberately omits​

  • No example passwords, no sample JWTs with real signatures, no variable names from .env files.
  • No “use this hostname” guidance-AIS provides endpoints per contract.

Decision PRO (staff browser app) - same ideas, different surface​

Decision PRO is a Next.js-style web application: users sign in through the product’s auth flow, then the app calls Pro Gateway with Bearer tokens (and may attach server-side credentials you never paste into tickets). Build-time settings often fix the public API origin seen by browsers, so changing the Pro hostname usually requires a coordinated rebuild with AIS-not only a DNS change. If staff see login loops or network errors without HTTP codes, start with Troubleshooting (bank view).

Next: Environments · Back: Overview