Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (3.9)
  3. Reference
  4. Securing
  5. Anypoint Enterprise Security

  6. Authorization Grant Types

Authorization Grant Types

There are four ways that a consumer can obtain authorization to dance with an OAuth service provider.

  1. Authorization Code

  2. Implicit

  3. Resource Owner Password Credentials

  4. Client Credentials

The sections below offer brief descriptions of each type of authorization grant, listed according to the level of security, in descending order. Refer to the Mule Secure Token Service document for details regarding OAuth Roles and the OAuth dance.

Authorization Code

For a service provider, this grant type involves the use of both an authorization server (responsible for confirming and granting permission to access the protected resource) and a resource server (responsible for providing access to the protected resource). Though described as independent servers, the authorization and resource entities actually reside on the same Mule server. A consumer must ask for a service provider’s permission to ask for protected resources, then it can ask for the protected resources.

An OAuth dance that involves an Authorization Code grant type proceeds as follows:

  1. Client app wants to use data (protected resource) housed by service provider, so initiates a request to access the data to the service provider.

  2. Client app calls the service provider’s authorization server, providing its client ID to confirm that it is a registered client of the Service Provider.

  3. Client app, using a login page supplied by the service provider, asks that the resource owner use the access credentials to authenticate themselves to the service provider.

  4. After confirming that the client ID is valid (i.e. the client app has previously registered with the service provider), and authenticating the resource owner via login credentials, the service provider returns authorization code.

  5. Client app calls the authorization server again, providing its authorization code, client ID (again), and client secret.

  6. Service provider returns a token in which it specifies the scope.

  7. Client app calls the resource server, providing the token, to request protected resource (data).

  8. Service provider delivers protected resource.

This type of authorization grant is especially secure because it authenticates the client and transmits the token without exposing the token to unauthorized parties, including the resource owner.

Implicit

As with the Authorization Code, an Implicit grant type involves both an authorization server and a resource server. However, rather than taking the extra steps to authenticate a client application via authorization code and client secret, the service provider authenticates a client based upon its client ID, then simply hands over the token to access the protected resource.

An OAuth dance that involves an Implicit grant type proceeds as follows:

  1. Client app wants to use data (protected resource) housed by service provider, so initiates a request to access the data to the service provider.

  2. Client app calls the service provider’s authorization server, providing its client ID to confirm that it is a registered client of the Service Provider.

  3. Client app, using a login page supplied by the service provider, asks that the resource owner use the access credentials to authenticate themselves to the service provider.

  4. After confirming that the client ID is valid (i.e. the client app has previously registered with the service provider), and authenticating the resource owner via login credentials, the service provider returns a token.

  5. Client app calls the resource server, providing the token, to request protected resource (data).

  6. Service provider delivers protected resource.

A simplified version of Authorization Code, the Implicit grant type optimizes performance for clients implemented in a browser using a scripting language, such as Javascript. However, this grant type may expose the token to the resource owner, or the resource owner’s user-agent.

Resource Owner Password Credentials

For this type of authorization, a client application simply demands that the resource owner share their service provider login credentials. The client app then accesses the service provider and logs into the resource owner’s account using the shared login credentials. The service provider accepts the valid login credentials and grants the client app full access to the resource owner’s account. The resource owner, in this case, must trust the client app not to abuse their trust in sharing access to private data.

An OAuth dance that involves Resource Owner Password Credentials proceeds as follows:

  1. Resource owner provides access credentials to the client app_._

  2. Client app calls service provider, providing client ID to confirm that it is a registered client of the Service Provider, and the access credentials for the protected resource, and requests a token.

  3. Service provider authenticates the client app and validates the access credentials, then issues a token.

  4. Client app calls the resource server, providing the token, to request protected resource (data).

  5. Service provider delivers protected resource.

Offering a much shorter version of the OAuth Dance, this type of authorization grant optimizes performance at the expense of sharing secure access credentials.

Client Credentials

For this type of authorization, a client app requests access to data that is not associated with a particular resource owner. Because no protected resources are involved, a service provider must only verify the client as valid. This type of OAuth interaction is sometimes referred to as "two-legged OAuth" because it involves only two roles: service provider, and an client app. The other three authorization types involve a third role, resource owner, thus are sometimes referred to as "three-legged OAuth".

An OAuth dance that involves Client Credentials proceeds as follows:

  1. Client app calls the authorization server, providing client ID to confirm that it is a registered client of the Service Provider.

  2. After confirming that the client ID is valid (i.e. the client app has previously registered with the service provider), the service provider returns a token, specifying the scope.

  3. Client app call the resource server, providing the token, to request specific data.

  4. Client app retrieves the data.

Typically, this authorization grant applies when the the client is also the resource owner.