Request and validate OAuth / OIDC tokens with APM

BIG-IP APM is able to request and validate OAuth2.0 and OpenID Connect tokens. It can act as Client, Resource Server and Authorization Server. In this article, I cover the use cases where APM acts as Resource Server (validating the tokens) and Client (requesting the tokens).

1. The tokens :

  • Access Token : this is the Oauth2.0 token (access_token). It is used for Authorization and has to be validated by the Resource server. This Resource Server will contact the Authorization server for validation (Out of Path validation - External)
    • Access Token can be either OPAQUE or JWT
  • ID Token : this is the OpenID Token (id_token). It is used by the client only in order to know you use the resource owner. For instance, when you see you name and your picture on the top right corner of an app, this comes from the ID_Token. This token is not user/validated by the Resource Server
    • ID Token is JWT only


2. OPAQUE vs JWT tokens :


  • Decodable
  • Encryptable
  • Can be validated against a preconfigured JWKS in-box or externally


  • Not decodable (opaque)
  • Proprietary format, might be any length, and must be unique
  • Must be validated in out-of-path HTTP request to the originating provider (the Authorization Server)


3. Token validation :

     OAuth Scope agent is used to validate an Access Token

  • either against an internal JSON web key set (JWKS) if the Access Token is JWT via an APM provider configuration (Azure AD uses JWT only)
  • or externally via HTTPS if the Access Token is Opaque. JWKS is faster because we don't have an extra HTTP transaction.

     Oauth Scope agent is used when APM is RS and the request from the client (APM or mobile app) has a authorization bearer header. Either with Opaque (External) or JWT token (Internal).


With Opaque token, if the RS needs more information about the user, it needs to request an OpenID Connect UserInfo by presenting the access_token to the AS.

The opaque scope provides with several information but it depends of the AS. For Google, an OIDC userInfo is needed to get the First and Last names.


4. Token Request :

    Oauth Client agent is used to request the Access token and id_token when APM is deployed as Oauth Client. To do so, 2 grant types are available (Code and password)

   With Authorization code grant, the Client agent exchanges an Authorization code for an access_token code + id_token (if OIDC used).

   When the Oauth Client gets the access_token (and id_token), the Oauth scope agent validates them.



Published May 06, 2019
Version 1.0

Was this article helpful?


  • Hi Mattieu, Thanks for this article, I have followed and configured the same for my F5 APM. But the issue is our F5 APM is able get the auth code from auth server but during the exchange for access token we are getting error as 'HTTP error 503, DNS lookup failed', checked few articles and even dns resolver settings are fine. 

    Any idea, where could be the issue?