OAuth and OpenID Connect - Made easy with Access Guided Configurations templates



OpenID Connect (OIDC) is an open authentication protocol that works on top of the OAuth 2.0 framework. The purpose of OIDC is for users to provide one set of credentials and access multiple sites. Each time users sign on to an application or service using OIDC, they are redirected to their OP (OpenID Provider), where they authenticate and are then redirected back to the application or service. 

OpenID is decentralized and not owned by anyone, nor should it be. Today, anyone can choose to use an OpenID or become an OpenID Provider for free without having to register or be approved by any organization.


OpenID Connect adds an identity layer on top of OAuth 2.0. When configured as an OAuth client / resource server, Access Policy Manager (APM) can interact with an OpenID Connect provider to get this data:
APM can make UserInfo requests to an endpoint that is specified for that purpose on an OAuth provider. APM supports UserInfo requests from the OAuth Scope and OAuth Client agents in an access policy or a per-request policy subroutine.
ID Token
As defined in the OpenID Connect core 1.0 spec, an ID Token contains claims by an authorization server about the authenticated user when using a client. APM obtains an ID Token from an OAuth provider when OpenID Connect is enabled in the OAuth Client agent in an access policy or a per-request policy. (The OAuth provider must support OpenID Connect.)

The OAuth 2.0 spec has four important roles:

OAuth role Description
Resource Owner Can grant access to a protected resource. A resource owner can be an end-user (person) or another entity.
Resource Server Hosts protected resources, and can accept and respond to requests for protected resources using access tokens.
Client Makes requests for protected resources on behalf of, and with authorization from, the resource owner. The client is an application.
Authorization Server Issues access tokens to the client after successfully authenticating the resource owner and obtaining authorization.


APM in OAuth resource server and client roles

When Access Policy Manager® (APM®) acts as an OAuth resource server, users can log on using external OAuth accounts to gain access to the resources that APM protects. External OAuth accounts can be social accounts, such as Facebook and Google, or enterprise accounts, such as F5 (APM) and Ping Identity (PingFederate).

In this configuration, APM becomes a client application to an external OAuth authorization server, such as F5, on another BIG-IP® system, or Google.

APM in the OAuth authorization server role

When Access Policy Manager® (APM®) acts as an OAuth authorization server, APM can grant authorization codes, access tokens, and refresh tokens, and APM can perform token introspection.

A great series was created by the APM guru Matt_Dierick 



More Federated labs can be access through Lab docs,


 Lab walk through

Access Guided Configuration support

Here's the support matrix for the templates using OAuth.
Use case/Component Version Compatible BIG-IP versions
OAuth Authorization Server 4.3.0 14.1.x, 15.0.x, 15.1.x, 16.0.x, 16.1.x
OAuth Client and Resource Server 4.4.0 14.1.x, 15.0.x, 15.1.x, 16.0.x, 16.1.x

UDF Lab access: https://udf.f5.com/b/cd258f67-afbd-45c8-a2c9-9201a9f2f6c4#components

Lab steps summary

  1. Create DNS Resolver.

  2. From Access Guided configuration choose proper template.

  3. Create OAuth Provider.

  4. Create OAuth Server.

  5. Create OAuth Policy (Scope).

  6. Create Virtual Server.


  • Single Sign-On configurations.

Lab configurations steps

Create DNS Resolver

 This DNS resolver will be responsible for resolving the dns name for the Identity provider URL.

Create the Forward zone to reach (if you are using DNS Proxy, specify it)

- Either use the OpenID provider zone name or use (.) to forward all queries. 

Note, DNS Address needs to be reachable over TMM interface (not mgmt interface).

Access Guided configuration template

In our case we are going to deploy F5 as Client and Resoure Server

Select the proper DNS Resolver



Create OAuth Provider, Server and Policy

Audience: Use the Client ID provided by the OpenID provider.

Below we select the OAuth provider and configure the server and scope settings.

Create Virtual Server

Configure the required virtual server settings

Assign the pool to the policy


And that's it you have the configurations ready, and can start testing them,

Below is the testing behavior.

1- Access URL for the virtual server.

 2- User is redirected to google for user authentication.

3- User authentication pass successfully.

Access OAuth dashboard


Updated Feb 28, 2023
Version 2.0

Was this article helpful?

No CommentsBe the first to comment