Token Verification

Assumption

• All parties are registered with Sahamati and have entries in the Central Registry and Keycloak Token Server.

Key Terms

Resource Server

This is the entity that is servicing the API request. For e.g. if an FIU calls and AA’s POST /Consent API, the AA is the Resource Server.

Client

This is the entity making the API call. In the earlier example, the FIU is the Client.

Generating a new token

The Client calls the token server API with its ClientID and Secret to receive a new token.

Token Usage

The Client will provide the token as aa_api_key in headers of all API calls made to the Resource Server.

Token Verification by Resource Server

On receiving the API call, the Resource Server will perform the following checks:

1. Decode token provided in aa_api_key (it’s a base-64 encoded JWT token).

2. Verify token issuer authenticity – i.e. verify if the token was generated by Sahamati Token Server:

   1. Retrieve Sahamati public key from CR.

   2. Verify the token signature using the Sahamati public key.

3. Verify token validity, check token has not expired:

   TokenClaims.exp > TokenClaims.iat AND IsInFuture(TokenClaims.exp)

4. Verify token ownership: This will verify the owner of the token (as recognized by Sahamati) is also the client calling the API.

   1. Use token.entityID to look up CR and access the entity’s public key.

   2. Use public key to verify API signature provided in header.x-jws-signature field.