The AXA Partners CLP API's incorporate OAuth 2.0 authentication meaning that only authorised entities can connect to our API. Every transaction is securitised by access tokens as well as data encryption. Various security strategies that we follow are as follows.

Authentication: The OAuth 2.0 authorization framework is a protocol that allows a user to grant a third-party web site or application access to the user's protected resources, without necessarily revealing their long-term credentials or even their identity.

OAuth 2.0 is the industry-standard protocol for authorization. The client credentials flow is typically used for machine-to-machine communication, where the client application needs to access resources under its control without user involvement. In this flow, the client (the application) directly exchanges its client credentials (client ID and client secret) for an access token from the authorization server. This access token can then be used to authenticate the client when making requests to the protected resources (API endpoints) on the resource server.

Here's how it works:

1. Client Registration: First of all, partner/client is registered with the AXA authorization server and a unique client ID and client secret is generated for the partner/client
2. Token Request: The partner/client application sends a POST request to the token endpoint, including their client credentials, the grant type (client_credentials), and any additional parameters required by the server. (ex. as follows)

curl -X POST https://.../oauth/token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -H 'Authorization: Basic <Base64 encoded (client id + ':' + client secret)> \
  -d 'grant_type=client_credentials&audience=https://.../apclp...v1-vrs'

3. Token Response: If the client/partner's credentials are valid and it is authorized to access the requested resources, the token endpoint responds with an access token. (ex. as follows)

{
  "access_token": "your_access_token",
  "scope": "",
  "token_type": "Bearer",
  "expires_in": 3600
}

4. Using the Access Token: The client/partner application can then use the obtained access token to make requests to the protected resources (API endpoints) by including the access token in the Authorization header of the HTTP request. (ex. as follows)

curl -X POST https://.../ \
  -H 'Authorization: Bearer your_access_token' \
  -H 'Content-Type: application/json' \
  -D '{}'

5. Access Control: The resource server validates the access token and, if it is valid, grants the client access to the requested API endpoints.

Authorization: Once authenticated, the API enforces access control to ensure that clients can only access the resources they are authorized to use. This is achieved through Role-Based Access Control (RBAC), scopes in the access token.

Encryption: Data exchanged between clients and the API is encrypted to protect it from unauthorized access. Transport Layer Security (TLS) is used to encrypt communications over the network.

Input Validation: All AXA CLP API's validate and sanitize input to prevent injection attacks and other security vulnerabilities. This includes validating query parameters, request bodies, and URL paths.

Rate Limiting: To ensure fair usage and system performance, all AXA CLP APIs enforces rate limits. Clients/partners should handle rate limit responses and implement appropriate backoff strategies.