About IG As an OAuth 2.0 Resource Server

OAuth 2.0 includes the following entities:

  • Resource owner: A user who owns protected resources on a resource server. For example, a resource owner can store photos in a web service.

  • Resource server: A service that gives authorized client applications access to the resource owner's protected resources. In OAuth 2.0, an authorization server grants authorization to a client application, based on the resource owner's consent. For example, a resource server can be a web service that holds a user's photos.

  • Client: An application that requests access to the resource owner's protected resources, on behalf of the resource owner. For example, a client can be a photo printing service requesting access to a resource owner's photos stored on a web service, after the resource owner gives the client consent to download the photos.

  • Authorization server: A service responsible for authenticating resource owners, and obtaining their consent to allow client applications to access their resources. For example, AM can act as the OAuth 2.0 authorization server to authenticate resource owners and obtain their consent. Other services, such as Google and Facebook can provide OAuth 2.0 authorization services.

The following image illustrates the steps for a client application to access a user's protected resources, with AM as the authorization server and IG as the resource server:

Handling OAuth 2.0 Requests as an OAuth 2.0 Resource Server
Handling OAuth 2.0 Requests as an OAuth 2.0 Resource Server

  • The application obtains an authorization grant, representing the resource owner's consent. For information about the different OAuth 2.0 grant mechanisms supported by AM, see OAuth 2.0 Grant Flows in AM's OAuth 2.0 Guide.

  • The application authenticates to the authorization server and requests an access_token. The authorization server returns an access_token to the application.

    An OAuth 2.0 access_token is an opaque string issued by the authorization server. When the client interacts with the resource server, the client presents the access_token in the Authorization header. For example:

    Authorization: Bearer 7af41ddd-47a4-40dc-b530-a9aa9f7ceda9

    Access_tokens are the credentials to access protected resources. The advantage of access_tokens over passwords or other credentials is that access_tokens can be granted and revoked without exposing the user's credentials.

    The access_token represents the authorization to access protected resources. Because an access_token is a bearer token, anyone who has the access_token can use it to get the resources. Access_tokens must therefore be protected, so that requests involving them go over HTTPS.

    In OAuth 2.0, the token scopes are strings that identify the scope of access authorized to the client, but can also be used for other purposes.

  • The application supplies the access_token to the resource server, which then resolves and validates the access_token by using an access_token resolver, as described in Access Token Resolvers.

    If the access_token is valid, the resource server permits the client access to the requested resource.

Read a different version of :