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

Introduction

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:

UserInfo

requests

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
https://www.youtube.com/watch?v=vpYfm_YCBRA

https://www.youtube.com/watch?v=JuVLwbffQ8s

https://www.youtube.com/watch?v=ABt3UD5q7f4

More Federated labs can be access through Lab docs,

https://clouddocs.f5.com/training/community/iam/html/archived/archived.html