API Proxy - Authentication Specifics to Consider

Owned by ivan.neganov (Unlicensed)
Last updated: Mar 24, 2021
2 min read

Let us look at a typical scenario: the client (Blazor web assembly, plain JavaScript, Angular, etc.) acquires an access token and passes it along with an HTTP post request to a microservice residing behind an API Proxy. The following diagram illustrates it:

When putting a microservice behind an API Proxy, which will handle authentication, one needs to decide whether to authenticate the request again once it reaches the microservice. As illustrated in the diagram the answer is “yes” in order to fulfil the recommendations for microservices security listed here and here.

In doing so we are passing identity around in an access token. In this architecture interpretation of the identity (authentication) and making decisions on what permissions it has (authorization) are handled by individual microservices. The steps on this diagram are as follows:

  1. User logs in to an application. Authentication request is sent to Azure AD as described earlier. An access token is returned.

  2. A request is made to a URI “/doSomething” with this token.

  3. The API Proxy authenticates the request. Since the token is a JWT bearer token, it contains a signature encrypted either RS256 (asymmetric) or HS256 (symmetric) algorithm. In the former case, in order to validate token’s signature the authentication logic may require a public key certificate, and issue an HTTPS GET request to a JWK Set resource URI, specified in the “x5u” field of the token, to obtain it.

  4. The request is then passed on to the microservice (once any policies configured on the API Proxy are applied).

  5. Microservice repeats the token validation (authentication) done by the API Proxy in step #3 above. The important part here is that the request to JWK Set URI will need to be proxied through the API Proxy as the microservice endpoint will typically not be exposed outside the cluster.

  6. Upon successful authentication and authorization the microservice fulfills the request and sends back a response to the client. It can be a 200 (OK) or 202 (accepted), or any other HTTP standard response.

The primary concern with the described use case is configuring API Proxy such that it allows authentication-related traffic between microservices and Azure AD, while hiding their endpoints from the public Internet.