Get an OAuth 2.0 access token

Use the OAuth 2.0 JWT bearer flow to obtain an access token for inbound API calls.

Inbound D1 APIs use the OAuth 2.0 JWT bearer flow (RFC 7523). Your system sends a signed JSON Web Token (JWT) to /oauth2/token to obtain an access token.

D1 can also secure outbound APIs with OAuth 2.0 on request. Refer to the outbound OpenAPI spec for the supported flow.

OAuth 2.0 JWT bearer flow

Use the inbound OpenAPI spec for the full /oauth2/token definition.

Every resource of the backend to backend API is protected. In order to gain access to it, the previously generated Access Token has to be sent along with the HTTP request in the Authorization header using the Bearer schema:

Authorization: Bearer <access_token>

The access token that is generated has a 15 minute lifespan, so it can be used for 15 minutes only, after which the client will have to call back the /oauth2/token API to get a fresh new token. For performance reasons, if your token is still within its validity period, we recommend that you reuse it rather than calling the /oauth2/token API before every API call.

JSON Web Token (JWT)

/oauth2/token REST API is requesting a JSON Web Token (JWT) authentication (rfc7519). It is assumed that the clients of this API are capable of issuing valid JWT tokens.

JWT tokens may be obtained by requesting them from an Identity Provider (such as Keycloak) or created manually. In both cases, the public key to be used for the signature verification has to be provisioned in the API provider system.

In the case where no Identity Provider is available, then the following section describes how to generate JWT tokens and the cryptographic keys that will be used to issue and verify the JWT.

Algorithms

Only the JWTs signed with algorithm "ES256" are supported. See JSON Web Algorithms (JWA) (rfc7518).

The JWT security is limited to asymmetric cryptography algorithms in order to avoid storing shared secrets in the back-end server. As a result, the back-end server only stores the public keys used to verify the signature of the tokens.

JWT format

A JWT consists of three parts separated by dots (.):

• Header

• Payload

• Signature

Therefore, a JWT typically looks like the following: hhhhhhh.pppppppp.ssssssssss

Header

The header part contains the algorithm to use and the type of token to generate.

The kid is mandatory and will be used to determine the correct key among multiple possible public keys from the same customer.

Header example:

{
  "alg": "ES256",
  "typ": "JWT",
  "kid": "your_tenant_key_id"
}

Payload

The Payload can contain the following fields:

Parameter	Description
iss	The issuer of the JWT. It shall be the merchantGatewayId for inbound APIs and d1 for outbound APIs and is used to lookup the onboarded public key.
sub	The subject must contain the technical identifier of the user. Here for backend to backend API, the sub is the merchantGatewayId.
exp	The token expiration time expressed as the number of seconds since Jan 1, 1970 (Epoch time) in UTC. Maximum value is current date/time + 15 minutes.
aud	The aud field identifies the authorisation server as an intended audience. On its side, the authorisation server must verify that it is an intended audience for the token. Use the authorisation server’s URL for the audience value: staging = stg , production = prd

JWT Expiration Notes

The exp value is checked against maximum expiration period. If the JWT exp value exceeds the maximum expiration period the JWT is automatically considered invalid and the request becomes unauthenticated.

Payload Example

{
  "iss": "d1",
  "sub": "MGW_ID",
  "exp": 1545222654,
  "aud": "stg"
}

JWT signature

A cryptographic hash of both the header and the payload.

These parts are Base64URL encoded and concatenated, separated by single dots ('.').

How to generate the key pair

You may use the openssl tool to generate a key pair with the following commands:

Example (ES256)

Generate Private Key that will be used on issuer side that MUST be securely protected in your environment.

> openssl ecparam -name prime256v1 -genkey -noout -out customer-jwt-priv-key.pem

Generate Public Key that MUST be configured in D1.

> openssl ec -in customer-jwt-priv-key.pem -pubout > customer-jwt-pub-key.pem

The generated private key will be used to sign the JWTs on the client side and the generated public key will be provisioned into the server side with the kid to verify the signature of those JWTs (exchanged between Customer and Thales during Onboarding).

How to generate the JWT

There are many tools available to help with JWT generation.

Here is an example of how to generate it using tiny NodeJS library:

/*
Please install *jose* library in your project.
https://www.npmjs.com/package/jose

For this example we use 3.19.0
*/
const { SignJWT } = require("jose/jwt/sign");
const { createPrivateKey } = require("crypto");

const alg = "ES256";
const kid = "your_tenant_key_id";
const iss = "your_issuer";
const aud = "your_audience";
const expirationTime = "3mins";
const sub = "our_user_for_audit";

const privateKeyPem = `-----BEGIN EC PRIVATE KEY----- 
MHcCAQEEILlIXMnH1if8EuWykPmWw/LyXZuoNVCzMp3Yhbj9/sEUoAoGCCqGSM49 
AwEHoUQDQgAE6swczLIRn/lPxQPpdUb2pHjCr0YeC02lkG7vMmqCNpalwIQSl+TR 
fZVDwCKJmajRgK3+n5SyAgCp4oH8qNluwQ==
-----END EC PRIVATE KEY-----`;

async function generateJwt() {
  const privateKey = createPrivateKey(privateKeyPem);

  console.log(
    await new SignJWT({})
      .setProtectedHeader({ alg, kid })
      .setIssuedAt()
      .setIssuer(iss)
      .setAudience(aud)
      .setExpirationTime(expirationTime)
      .setSubject(sub)
      .sign(privateKey)
  );
}

(async () => {
  await generateJwt();
})();

Example JWT output

eyJhbGciOiJFUzI1NiIsImtpZCI6InlvdXJfdGVuYW50X2tleV9pZCJ9.eyJpYXQiOjE2MzYwMzMxODYsImlzcyI6InlvdXJfaXNzdWVyX2lkIiwiYXVkIjoieW91cl9hdWRpZW5jZSIsImV4cCI6MTYzNjAzMzM2Niwic3ViIjoib3VyX3VzZXJfZm9yX2F1ZGl0In0.lgVzN8k9IGcv1s-FZACpEyVxXcS9LAh4ahY3DO5Fg6MRl-Twa_wVAfw_Oe0XiH1Am-RFfafgDrepNi3Jz05Gvg