OAuth and OpenID Connect - Made easy with Access Guided Configurations templates
- Lab walk through
- Access Guided Configuration support
- Lab steps summary
- Create DNS Resolver.
- From Access Guided configuration choose proper template.
- Create OAuth Provider.
- Create OAuth Server.
- Create OAuth Policy (Scope).
- Create Virtual Server.
- Single Sign-On configurations.
- Lab configurations steps
- Create DNS Resolver
- Access Guided configuration template
- Create OAuth Provider, Server and Policy
- Create Virtual Server
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.
The OAuth 2.0 spec has four important roles:
|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 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.
More Federated labs can be access through Lab docs,
Lab walk through
Access Guided Configuration supportHere's the support matrix for the templates using OAuth.
|Compatible BIG-IP versions
|OAuth Authorization Server
|14.1.x, 15.0.x, 15.1.x, 16.0.x, 16.1.x
|OAuth Client and Resource Server
|14.1.x, 15.0.x, 15.1.x, 16.0.x, 16.1.x
Lab steps summary
Create DNS Resolver.
From Access Guided configuration choose proper template.
Create OAuth Provider.
Create OAuth Server.
Create OAuth Policy (Scope).
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.
Access OAuth dashboard