OAuth 2.0 Grant Types

This topic tells you how OAuth 2.0 grant types work with different app types.

Authorization Code Grant Type

The authorization code grant type is the most commonly used grant type. This grant type is for server-side apps.

Authorization Code Grant Type Roles

The Authorization Code grant type uses the following roles:

• Resource Owner: A person or system capable of granting access to a protected resource.
• Application: A client that makes protected requests using the authorization of the resource owner.
• Authorization Server: The Single Sign‑On server that issues access tokens to client apps after successfully authenticating the resource owner.
• Resource Server: The server that hosts protected resources and accepts and responds to protected resource requests using access tokens. Apps access the server through APIs.

Authorization Code Grant Type Flow

The following diagram shows the flow for the Authorization Code grant type:

The flow of the Authorization Code grant type is:

1. Access Application: The user accesses the app and triggers authentication and authorization.
2. Authentication and Request Authorization: The app redirects the user to the authorization server where it prompts the user for their username and password. The first time the user goes through this flow for the app, the user sees an approval page. On this page, the user can choose permissions to authorize the app to access resources on their behalf.
3. Authentication and Grant Authorization: The authorization server receives the authentication and authorization grant.
4. Send Authorization Code: After the user authorizes the app, the authorization server sends an authorization code to the app using a redirect.
5. Request Code Exchange for Token: The app uses the authorization code to request an access token from the authorization server. This gives the app access to the approved permissions.
6. Issue Access Token: The authorization server validates the authorization code and issues an access token.
7. Request Resource w/ Access Token: The app attempts to access the resource from the resource server by presenting the access token.
8. Return Resource: If the access token is valid, the resource server returns the resources that the user authorized the app to receive.

The resource server runs in VMware Tanzu Application Service for VMs (TAS for VMs) under a given space and org. Developers set the permissions for the resource server API endpoints. To do this, they create resources that correspond to API endpoints secured by Single Sign‑On. Apps can then access these resources on behalf of users.

Client Credentials Grant Type

This grant type is for apps that can request an access token and access resources on its own. These apps often use services that call APIs without users.

Client Credentials Grant Type Roles

The Client Credentials grant type uses the following roles:

• Application: A client that makes protected requests using the authorization of the resource owner.
• Authorization Server: The Single Sign‑On server that issues access tokens to client apps after successfully authenticating the resource owner.
• Resource Server: The server that hosts protected resources and accepts and responds to protected resource requests using access tokens. Apps access the server through APIs.

Client Credentials Flow

The following diagram shows the flow for the Client Credentials grant type:

The flow of the Client Credentials grant type is:

1. Authenticate w/ Client ID and Secret: The app authenticates with the authorization server using its client ID and client secret.
2. Issue Access Token: The authorization server validates the client ID and client secret and issues an access token.
3. Request Resource w/ Access Token: The app attempts to access the resource from the resource server by presenting the access token.
4. Return Resource: If the access token is valid, the resource server returns the resources to the app.

The resource server runs in Single Sign‑On under a given space and org. Developers set the permissions for the resource server API endpoints. To do this, developers create resources that correspond to API endpoints secured by Single Sign‑On. Administrators can create admin clients to perform automated management actions without a user. See Create Admin Client.

Resource Owner Password Grant Type

For Native Mobile and Desktop apps, Single Sign‑On for VMware Tanzu Application Service supports the Resource Owner Password OAuth 2.0 grant type. This password grant type is for highly trusted apps where resource owners share their credentials directly with the app.

Resource Owner Password Grant Type Roles

The Resource Owner Password grant type uses the following roles:

• Resource Owner: A person or system capable of granting access to a protected resource.
• Application: A client that makes protected requests using the authorization of the resource owner.
• Authorization Server: The Single Sign‑On server that issues access tokens to client apps after successfully authenticating the resource owner.
• Resource Server: The server that hosts protected resources and accepts and responds to protected resource requests using access tokens. Apps access the server through APIs.

Resource Owner Password Flow

The following diagram shows the flow for the Resource Owner Password grant type:

The flow of the Resource Owner Password grant type is:

1. Authenticate w/ Username and Password: The user authenticates with the app using their username and password.
2. Send Username/Password: The app sends the username and password to the authorization server for validation.
3. Issue Access Token: The authorization server validates the username and password and issues an access token.
4. Request Resource w/ Access Token: The app attempts to access the resource from the resource server by presenting the access token.
5. Return Resource: If the access token is valid, the resource server returns the resources that the user authorized the app to receive.

The resource server runs in TAS for VMs under a given space and orgn. Developers set the permissions for the resource server API endpoints. To do this, they create resources that correspond to API endpoints secured by Single Sign‑On. Apps can then access these resources on behalf of users.

Implicit Grant Type

The Implicit grant type is for apps with a client secret that is not guaranteed to be confidential.

Implicit Grant Type Roles

The Implicit grant type uses the following roles:

• Resource Owner: A person or system capable of granting access to a protected resource.
• Application: A client that makes protected requests using the authorization of the resource owner.
• Authorization Server: The Single Sign‑On server that issues access tokens to client apps after successfully authenticating the resource owner.
• Resource Server: The server that hosts protected resources and accepts and responds to protected resource requests using access tokens. apps access the server through APIs.

Implicit Flow

The following diagram shows the flow for the Implict grant type:

The flow of the Implicit grant type is:

1. Access Application: The user accesses the app and triggers authentication and authorization.
2. Authentication and Request Authorization: The app prompts the user for their username and password. The first time the user goes through this flow for the app, the user sees an approval page. On this page, the user can choose permissions to authorize the app to access resources on their behalf.
3. Authentication and Grant Authorization: The authorization server receives the authentication and authorization grant.
4. Issue Access Token: The authorization server validates the authorization code and returns an access token with the redirect URL.
5. Request Resource w/ Access Token in: The app attempts to access the resource from the resource server by presenting the access token in the URL.
6. Return Resource: If the access token is valid, the resource server returns the resources that the user authorized the app to receive.

The resource server runs in TAS for VMs under a given space and org. Developers set the permissions for the resource server API endpoints. To do this, they create resources that correspond to API endpoints secured by Single Sign‑On. apps can then access these resources on behalf of users.