An API is exposed to customers for retrieval of resources. We would like to use OAuth to authorize access to this API via the Authorization Code grant type defined in the OAuth 2.0 specification. The solution must provide both the resource server and the authorization server.
The Layer 7 OAuth Toolkit allows for protection of resources and can play multiple roles in the OAuth protocol flow. In this case, we will demonstrate how to establish both an authorization server and a resource server in the Layer 7 Policy Manager and then define specific parameters needed for the Authorization Server grant type.
The OAuth Toolkit is divided into multiple sections representing the various versions of the specification. For this example, we will focus on the OAuth 2.0 section. The policies for 2.0 include:
Using these building blocks, we can implement any of the core grant types across multiple architectures, including both two- and three-legged scenarios.
The OAuth 2.0 Authorization Code grant type provides for an intermediate step between authentication and access. The resource owner is redirected to the authorization server and expresses authorization for the resource in question. The authorization server then redirects back to the client app with an authorization code. The client application presents this authorization code, along with its own credentials, back to the authorization server, to obtain an access token (and optionally a refresh token). The client then uses the access token to call the service on behalf of the resource owner. A refresh token can be used to extend the lifetime of this session.
Let’s walk through each of the moving parts in this scenario. First, we test the application. The video at the bottom of this page demonstrates how the OAuth test application included with the Toolkit can be used to:
When the handshake is initiated, the resource owner is redirected to the authorization server. This server’s behavior can be modified in the “OAuth Authorization Server v2.0” policy in the Toolkit. The video demonstrates how to:
The authorization code provided to the client app can be exchanged for an access token. The access token is then used to gain access to the resource server – the behavior of the resource server can be customized as well. The video demonstrates how to:
The authorization fragment returns information about the current session to the resource server, allowing for identity-based policy logic: