--- schema_version: "1" id: 57d0562f9160749a8d67c4c5bc7c172903488bde6248580281103e0e79f9b4ff title: OAuth Authorization Grant Types collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/mule-runtime/4.3/authorization-grant-types.md canonical_url: https://docs.mulesoft.com/mule-runtime/4.3/authorization-grant-types source_site: docs.mulesoft.com content_type: documentation content_hash: 5c4ca639f245b1472b0d5eb359d1bda12b978ce7ff71f25a660a96bf65a3682f description: MuleSoft Documentation Site release: "4.3" latest: false --- --- product: Mule Runtime version: 4.3 keywords: http, authentication, security, users, connectors, anypoint, studio, oauth --- # OAuth Authorization Grant Types > For the full documentation index, see: https://docs.mulesoft.com/llms.txt There are four types of authorization grants that an OAuth consumer (that is, a client app) can use to obtain access to a protected resource from an OAuth service provider: - [Authorization Code](#authorization-code) - [Implicit](#implicit) - [Resource Owner Password Credentials](#resource-owner-password-credentials) - [Client Credentials](#client-credentials) For information about the the OAuth authorization framework, see RFC 6749, "The OAuth 2.0 Authorization Framework." ## Authorization Code The Authorization Code grant type uses 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 servers reside on the same Mule server. With the Authorization Code grant type, a client app must request an authorization code from the service provider before it can request the token that will grant access to protected resources. The Authorization Code grant type is especially secure, because it authenticates the client and transmits the access token without exposing it to unauthorized parties, including the resource owner. An OAuth dance that uses an Authorization Code grant type works as follows: 1. Client app wants to use a protected resource controlled by the service provider, so the client initiates a request to access the resource. 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 uses a login page supplied by the service provider to authenticate itself to the service provider. 4. After confirming that the client ID is valid (that is, the client app had previously registered with the service provider), and authenticating the resource owner’s login credentials, the service provider returns an authorization code. 5. Client app calls the authorization server again, and provides the authorization code, client ID (again), and client secret. 6. Service provider returns an access token. 7. Client app calls the resource server, providing the access token to request the protected resource. 8. Service provider delivers the protected resource. ## Implicit As with the Authorization Code grant type, 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 by using an authorization code and client secret, the service provider does the following: - Authenticates a client based upon its client ID. - Provides the access token to access the protected resource. The Implicit grant type optimizes performance for browser clients that use a scripting language, such as Javascript. However, this grant type can expose the access token to the resource owner or the resource owner’s user-agent. An OAuth dance that uses an Implicit grant type works as follows: 1. 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. 2. Client app uses a login page supplied by the service provider to request that the resource owner authenticate itself to the service provider. 3. After confirming that the client ID is valid (that is, the client app had previously registered with the service provider), and authenticating the resource owner’s login credentials, the service provider returns an access token. 4. Client app calls the resource server, providing the access token to request the protected resource. 5. Service provider delivers the protected resource. ## Resource Owner Password Credentials With the Resource Owner Password Credentials grant type, a client application demands that the resource owner share its service provider login credentials. The client app then uses these credentials to access the service provider and log into the resource owner’s account. The service provider accepts the valid login credentials and grants the client app full access to the resource owner’s account. This type of authorization optimizes performance at the expense of sharing secure access credentials. The resource owner must trust the client app not to share access to private data. An OAuth dance that uses the Resource Owner Password Credentials grant type works as follows: 1. Resource owner provides access credentials to the client app. 2. Client app calls the service provider to request an access token. During the call, the client provides the client ID to confirm that it is a registered client of the service provider. It also provides the access credentials for the protected resource. 3. Service provider authenticates the client app and validates the access credentials. Then it issues an access token. 4. Client app calls the resource server, providing the access token to request access to the protected resource. 5. Service provider delivers the protected resource. ## Client Credentials With the Client Credentials grant type, a client app requests access to data that is not associated with a particular resource owner. With this grant type, a service provider must only verify that the client as valid. This type of OAuth interaction is sometimes referred to as "two-legged OAuth" because it involves only two roles: the service provider and a client app. The other three authorization types involve a third role, the resource owner. Thus, they are sometimes referred to as "three-legged OAuth". The Client Credentials grant type typically applies when the the client is also the resource owner. An OAuth dance that uses the Client Credentials grant type works as follows: 1. Client app calls the authorization server, providing a client ID to confirm that it is a registered client of the service provider. 2. After confirming that the client ID is valid (that is, the client app had previously registered with the service provider), the service provider returns an access token. 3. Client app calls the resource server, providing the access token to request the protected resource. 4. Client app retrieves the protected resource. ## See Also - [Mule Secure Token Service](https://docs.mulesoft.com/mule-runtime/4.3/mule-secure-token-service)