Manual Chapter : OAuth Overview
Applies To:Show Versions
- 15.0.1, 15.0.0
APM OAuth 2.0 support
OAuth roles that APM supports
On a single BIG-IP system, Access Policy Manager (APM) can be configured to act as an OAuth 2.0 client and resource server, or to act as an OAuth 2.0 authorization server, or to act as both.
For APM to act in both OAuth roles on one BIG-IP system requires two virtual servers, one for each role, and two hostnames, one for each role.
OAuth 2.0 roles
OAuth 2.0 specification RFC 6749 defines the roles in this table.
Can grant access to a protected resource. A resource owner can be an end-user (person) or another entity.
Hosts protected resources, and can accept and respond to requests for protected resources using access tokens.
Makes requests for protected resources on behalf of, and with authorization from, the resource owner. The client is an application.
Issues access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
APM in OAuth resource server and client
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
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.
About OAuth database backup
If the BIG-IP system on which you are running Access Policy Manager (APM) is set up as an OAuth Server, it may also be configured for High Availability (HA). In that case, the OAuth database on the active system is automatically synchronized with one or more redundant systems within a device group.
HA supports real-time synchronization of the BIG-IP configuration, including the OAuth database, and switching over seamlessly when needed. The redundant BIG-IP systems can reside in different data centers remote to each other, as long as they can reach each other through an IP network. No additional synchronization or switching over is required for the OAuth database. For details on configuring High Availability, refer to
BIG-IP Device Service Clustering: Administration.
In addition to the HA solution, you can also manually back up and restore systems using a UCS configuration archive. To do this, refer to the knowledgebase article:
K13132: Backing up and restoring BIG-IP configuration files with a UCS archiveon support.f5.com. The UCS archive contains all of the files you need to restore the current system configuration onto a new system, including all configuration files for the BIG-IP system, APM, and the OAuth database (if in use).
BIG-IP system for two OAuth roles
You can configure one BIG-IP system with Access Policy Manager (APM) acting in an OAuth 2.0 client / resource server role and in an OAuth 2.0 authorization server role.
- Configure APM to act as an OAuth client / resource server (or to act an OAuth resource server gateway).It doesn't matter whether you configure APM to act as an OAuth authorization server first or second. What's important is that you create separate virtual servers for each of the two configurations.
- Configure APM to act as an OAuth authorization server.In this step, be sure to configure a virtual server that is distinct from the one you configured for APM in the previous step.
- In your DNS configuration, configure two host names:
- Point one hostname to the virtual server configured for APM as an OAuth authorization server.
- Point the other hostname to the virtual server configured for APM in the other role (OAuth client / resource server or OAuth resource server gateway).
You have configured a BIG-IP system on which APM can play two OAuth roles.
Do not attempt to use a single FQDN to point to different ports on a single virtual server as an alternative; it does not work and is not supported.