AM as Client and Resource Server

When AM functions as an OAuth 2.0 client, it provides an session after successfully authenticating the resource owner and obtaining authorization. This means the client can then access resources protected by agents.

To configure AM as an OAuth 2.0 client, use OAuth 2.0/OpenID Connect nodes or modules as part of the authentication journey.

The following sequence diagram shows how the client gains access to protected resources in the scenario where AM functions as both authorization server and client:

OAuth 2.0 Client and Authorization Server

As the OAuth 2.0 client functionality is implemented as an AM authentication module or nodes, you do not need to deploy your own resource server implementation when using AM as an OAuth 2.0 client. Use web or Java agents or IG to protect resources.

Using Your Own Client and Resource Server

AM returns bearer tokens as described in RFC 6750, The OAuth 2.0 Authorization Framework: Bearer Token Usage. Notice in the following example JSON response to an access token request that AM returns a refresh token with the access token. The client can use the refresh token to get a new access token as described in RFC 6749:

{
  "expires_in": 599,
  "token_type": "Bearer",
  "refresh_token": "f6dcf133-f00b-4943-a8d4-ee939fc1bf29",
  "access_token": "f9063e26-3a29-41ec-86de-1d0d68aa85e9"
}

In addition to implementing your client, the resource server must also implement the logic for handling access tokens. The resource server can use the /oauth2/introspect endpoint to determine whether the access token is still valid, and to retrieve the scopes associated with the access token. For an example of the values returned by the endpoint, see "/oauth2/introspect".

AM is designed to let you plug in your own scopes implementation if the default implementation does not do what your deployment requires. See "Customizing OAuth 2.0 Scope Handling" for an example.

Related information: