# 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.