Keycloak is an open source Identity and Access Management server; we will use it for issuing of tokens.
The Authentication functionality is based on the Oauth2 (Open Authorization version 2) protocol, a standard and open protocol to secure API (Application Programming Interface).
The oauth2 protocol uses JWT (Web JSON token), described in RFC7519; it defines a JSON format scheme for the exchange of information between services in a secure way. The oauth2 flow requires that the client sends an authentication request to the server, the server generates a signed token and returns it to the client which, from that moment, uses it to authenticate subsequent requests

The JWT is composed by 3 part:

1. Header: Contains token format and type of encryption
2. Paylod : Define token properties:
   • General properties are:
     • iss (issuer): Contains the identification of those who have generated a token
     • sub (subject): Contains the token message
     • aud (audience): It is an array of values indicating the token abilities
     • exp (expiration): It is an integer (timestamp in seconds) that indicates how long the token is valid
     • nbf (not before): It is an integer (timestamp in seconds), that indicates the start date of token validity
     • iat (issued at): It is an integer (timestamp in seconds) that indicates the token generating date, it is used to know the age of a token
     • jti (jwt id): Unique id of token, in order to avoid generating two identical tokens
   • Custom properties are used to customize a token; in particular, we have defined for FINSEC:
     • x_organization: Contains the organization that it has required the token
     • x_role: Used to specify a custom role associated with a token; we will use this in the Authorization phase
     • Email: client email
     • Username: client username
   • Signature: The token signature done with HMAC algorithm

All this information will be used subsequently for authorization. The authorization feature is implemented with Role-based Access Control (RBAC) through the API GW, which determines whether the user/client has the authority to make a specific API request. At the same time, it is very important for the client to take into account the token expiration time, in order to renew it before the token is out of date, otherwise the client will not be able to make new API requests.
For Accounting we will generate logs based on the functionalities consumed by clients on FINSEC platform; these logs could be useful for an external billing system, in order to enable the Pay per Use model for the FINSEC platform. In particular, we rely on the ISTIO functionalities of:

• Observability: It allows collecting logs, metrics and events
• Traceability: it allows analyzing all incoming and outbound traffic on all services on HTTP, HTTP2 and gRPC

The integration between API Gateway and Keycloak will allow FINSEC to implement the OIDC authorization flow as shown in the figure below.

The client, using the Keycloak endpoint, sends with a POST their credentials to the server (Keycloak) to self-authenticate.

The server checks whether the credentials posted are correct. If so, Keycloak builds a JWT token using the secret key, this token will be signed and authenticated with its private key (only Keycloak needs to know the private key).
The client saves the token and inserts it in the “Authorization” HTTP header, for subsequent requests forwarded to API GW.

For each request API GW makes sure, through a call to Keycloak, that the token has been signed and authenticated with its private key and finally that it has not expired.
If all checks on JWT are passed, the API GW will treat the client as authenticated, after that API GW will check client has the right authorization for the specific request, if so then it manages the client as authorized and will manage the request, otherwise it will respond to the request with an HTTP 401 error code (unauthorized user).