Avi Load Balancer can act as a client and resource server for OAuth/ OIDC use cases.

Being a client and resource server, Avi Load Balancer will get the authorization code from the end user, exchange the authorization code with an access_token, validate the access_token, and allow the client to access the resource based on the token validation and authorization policies based on the claims.

The same virtual service will act as a client and resource server.

Request Flow

The request flow is explained as follows:



  1. The resource owner tries to access an application.

  2. The client (Avi Load Balancer) initiates the flow by directing the resource owner’s user-agent to the authorization endpoint. Avi Load Balancer as a client stores session information including its client identifier and a redirection URI/ call-back URI to which the authorization server will send the user agent back once the access is granted (or denied).

  3. The resource owner sends the request to the authorization server at the authorization endpoint.

  4. The authorization server authenticates the resource owner (using the user agent) and establishes whether the resource owner grants or denies the client’s access request. Assuming the resource owner grants access, the authorization server redirects the user agent back to the client using the redirection URI/call-back URI provided earlier (in the request or during client registration). The redirection URI includes an authorization code.

  5. The resource owner sends a request with the client redirect URL and the authorization code.

  6. The client requests an access_token from the authorization server’s token endpoint by including the authorization code received in the previous step. When making the request, the client authenticates with the authorization server using the client_id and client_secret.

  7. The authorization server authenticates the client and validates the authorization code. If valid, the authorization server responds with access_token and, optionally, a refresh token will be provided. If OIDC is enabled, id_token is also issued by the authorization server.

  8. Avi Load Balancer as a client sets a session cookie and sends a request to the resource owner with the resource URL.

  9. The resource owner sends a request with the session cookie. On receiving the request, Avi Load Balancer retrieves the access_token using the session cookie.

  10. Avi Load Balancer being the resource server validates the access_token. If the Access Token is of type JWT, Avi Load Balancer validates the access_token on its own. If the Access Token is of type Opaque, Avi Load Balancer sends the request to the introspection endpoint of the authorization server to validate the opaque token. Starting with Avi Load Balancer 22.1.3, caching of introspection data is supported to avoid communication between Avi Load Balancer (resource server) and the authorization server for each request.

  11. Based on the validation result, Avi Load Balancer will either provide access or deny it.

  12. If the access_token is validated, the request is sent to the back end server.

  13. The server responds.

  14. Avi Load Balancer sends the response to the resource owner. Further requests must carry the session ID and steps 10-14 must be followed.

Responsibilities of Avi Load Balancer Virtual Service as a Client and Resource Server

The responsibilities of the OAuth Client are:

  1. Redirecting an unauthenticated client to an authorization endpoint of the provider - Generating the state and nonce parameter for the same. Currently, the nonce is not generated since it is not mandatory for authorization code flow.

  2. Exchanging code with a token for retrieving Access Token and ID Token (in the case of OIDC).

  3. ID token validation (JWT) - OIDC mandates that access token hash must be validated.

  4. Storing the session information, such as Access Token, Refresh Token and relevant details from the ID Token.

  5. Creating the session cookie and setting the client response.

  6. Delegate the request to the resource server when the end-user presents a proper session cookie.

  7. Refreshing the access_tokens after expiry.

The responsibilities of the OAuth Resource Server are:

  • Validating access_token using:

    • JWT validation with JWKS URI downloaded from jwks_uri.

    • Introspection-based validation in the case of an opaque token.

Using Refresh Token to obtain a New Access Token (Using Avi Load Balancer)



When the request comes to the Avi Load Balancer Virtual Service, the Access Token is retrieved using the session cookie. If the Access Token is expired, Avi Load Balancer sends the refresh token to the token endpoint of the authorization server to get a new access_token. The authorization server responds with an access_token and id_token. Avi Load Balancer (client) validates the id_token, stores the id_token, and access_token, and updates the session cookie. Then the access_token is validated. If the validation is successful, access to the resource is granted.

Using UserInfo Endpoint



Note:

After the cookie is issued to the client, the rest of the request flow is the same as depicted in the request flow diagram above.

The UserInfo endpoint can be used to retrieve identity information about a user. Extract the user information from the UserInfo endpoint, if the UserInfo flag is configured under the OIDC parameters. If the UserInfo flag is not configured under the OIDC parameters, the user information is extracted from one of the claims in the id_token.