OAuth 2.0 Tutorial 2: The Authorization Code Grant Type

Video created by macsa06 on Jul 22, 2014

    The Problem

    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 Solution

    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:

    • A full implementation of an authorization server for distributing authorization and/or access tokens
    • A policy fragment, which references that implementation for runtime authorization
    • A sample resource server used to protect a specific API
    • Sample client applications that demonstrate each of the grant types

    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:

    • Initiate a new OAuth handshake
    • Refresh the current access token
    • Call an API using the access token

    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:

    • Customize the initial user interface or redirect to another web page
    • Choose an identity provider for authentication of the incoming credentials
    • Define a custom method for authenticating the client application when it requests an access token
    • Define specific rules pertaining to refresh token behavior

    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:

    • Insert the “OAuth 2.0 Runtime Authorization” fragment
    • Define any additional resource server policies based on metadata contained in the token


    The authorization fragment returns information about the current session to the resource server, allowing for identity-based policy logic: