Choosing an OAuth Grant Type

>About OAuth Clients
See OAuth Clients

>About the Sentinel IDP
See Sentinel Identity Provider (IDP)

Components of an OAuth Grant Type

You choose the appropriate grant type based on the security requirements, nature of the application, and the level of trust between different components. You select the best grant type according to the application type, API consumption context, and the Identity Provider (IDP) that you are using. This section describes these components, as shown in the following diagram.

In this section:

>Application Types

>API Consumer—Consumption Context—Authentication (AuthN) and Authorization (AuthZ)

>Identity Provider (IDP)

For more details on client credentials, authorization code, and PKCE, see OAuth Grant Types.

Application Types

The application type can be one of the following:

Application Type	Description
Software-as-a-Service (SaaS) application	Can be one of the following: >Single-Page Application (SPA). A SPA is a web application that operates within a single web page without a back end. As a user interacts with the SPA, content is dynamically rewritten without the need to refresh the web page. SPAs are considered public clients because they cannot safely store secrets. >Server-side web application. A traditional web application that runs on a web server and where the majority of the processing and logic is performed on the server instead of the client's device or web browser. By offloading the processing to the server, these applications can maintain the security required for OAuth authentication and authorization. After authentication, the web application exchanges the authorization code for an access token. This access token allows the web application to access protected resources on behalf of the user. Server-side web applications are considered confidential clients because the source code is safely stored and not available to users. This enables server-side web applications to maintain the confidentiality of their client secrets.
On-premises application	An on-premises application, which is a public client type. If the on-premises application does not have an authentication mechanism, the vendor can provide a portal or another solution for downloading or retrieving an offline token as a one-time step.

Application Type

Description

Software-as-a-Service (SaaS) application

Can be one of the following:

>Single-Page Application (SPA). A SPA is a web application that operates within a single web page without a back end. As a user interacts with the SPA, content is dynamically rewritten without the need to refresh the web page.

SPAs are considered public clients because they cannot safely store secrets.

>Server-side web application. A traditional web application that runs on a web server and where the majority of the processing and logic is performed on the server instead of the client's device or web browser. By offloading the processing to the server, these applications can maintain the security required for OAuth authentication and authorization. After authentication, the web application exchanges the authorization code for an access token. This access token allows the web application to access protected resources on behalf of the user.

Server-side web applications are considered confidential clients because the source code is safely stored and not available to users. This enables server-side web applications to maintain the confidentiality of their client secrets.

On-premises application

An on-premises application, which is a public client type.

If the on-premises application does not have an authentication mechanism, the vendor can provide a portal or another solution for downloading or retrieving an offline token as a one-time step.

API Consumer—Consumption Context—Authentication (AuthN) and Authorization (AuthZ)

The following table describes how authentication and authorization are handled in the context of Sentinel API consumption.

Access Token Issued for	Description
User	>An individual access token is issued on behalf of an individual user. This context requires user interaction, such as logging in. >Each access token contains user-specific information that includes the user's rights and permissions. >Refresh and logout handling is required for each access token.
Application	>An access token is issued on behalf of an application to enable access to protected, application-related resources. This context always uses the application's client credentials. >An access token contains application-specific information that includes the application's rights and permissions. Currently, with the Sentinel REST APIs, you can create only admin-type access tokens. >Only one access token is required for an instance. > All requests from users in the vendor's application use the same access token to consume Sentinel APIs. >The vendor application is responsible for allowing, disallowing, and filtering data for a specific user.

Access Token Issued for

Description

User

>An individual access token is issued on behalf of an individual user. This context requires user interaction, such as logging in.

>Each access token contains user-specific information that includes the user's rights and permissions.

>Refresh and logout handling is required for each access token.

Application

>An access token is issued on behalf of an application to enable access to protected, application-related resources. This context always uses the application's client credentials.

>An access token contains application-specific information that includes the application's rights and permissions. Currently, with the Sentinel REST APIs, you can create only admin-type access tokens.

>Only one access token is required for an instance.

> All requests from users in the vendor's application use the same access token to consume Sentinel APIs.

>The vendor application is responsible for allowing, disallowing, and filtering data for a specific user.

Identity Provider (IDP)

The Identity Provider (IDP) defines who authenticates the user or application.

Authentication Type	Sentinel IDP	Vendor IDP
User You can use one or both IDPs depending on your implementation.		(Optional)
Application

Authentication Type

Sentinel IDP

Vendor IDP

User

You can use one or both IDPs depending on your implementation.

(Optional)

Application

Selecting the Relevant OAuth Flow

The following tables offer the best practices for each of the application types.

>Server-Side Web Application (Confidential Client Type)

>Single Page Application (Public Client Type)

>On-Premises Application (Public Client Type)

Server-Side Web Application (Confidential Client Type)

API Consumption Context (AuthN/AuthZ)	IDP	Recommended Grant Type	Comments
User Context	Sentinel	Authorization Code	To ensure a seamless user experience when using the vendor application, the vendor can connect with Thales Customer Support to apply branding to the login, logout, and forgot password pages that are displayed from the Sentinel IDP. Additional steps may be required to configure the Sentinel IDP. Contact Thales Customer Support.
User Context	Vendor	Authorization Code	The Sentinel IDP may require configuration to integrate with the vendor IDP.
Application Context	Sentinel	Client Credentials	N/A
Application Context	Vendor	Client Credentials	N/A

Single Page Application (Public Client Type)

API Consumption Context (AuthN/AuthZ)	IDP	Recommended Grant Type	Comments
User Context	Sentinel	Authorization Code with PKCE	To ensure a seamless user experience when using the vendor application, the vendor can connect with Thales Customer Support to apply branding to the login, logout, and forgot password pages that are displayed from the Sentinel IDP. Additional steps may be required to configure the Sentinel IDP.
User Context	Vendor	Authorization Code with PKCE	The Sentinel IDP may require configuration to integrate with the vendor IDP.
Application Context	Sentinel	Client Credentials via the vendor back-end service	The SPA communicates with the vendor application's back-end service, which consumes the Sentinel APIs and uses the client credentials flow.
Application Context	Vendor	Client Credentials via the vendor back-end service	The SPA communicates with the vendor application's back-end service, which consumes the Sentinel APIs and uses the client credentials flow.

On-Premises Application (Public Client Type)

API Consumption Context (AuthN/AuthZ)	IDP	Recommended Grant Type	Comments
User Context (Browser)	Sentinel	Authorization Code with PKCE	To ensure a seamless user experience when using the vendor application, the vendor can connect with Thales Customer Support to apply branding to the login, logout, and forgot password pages that are displayed from the Sentinel IDP. Additional steps may be required to configure the Sentinel IDP. If the on-premises application does not have an authentication mechanism, the vendor can provide a portal or other solution for retrieving an offline token as a one-time step.
User Context (Browser)	Vendor	Authorization Code with PKCE	Additional steps may be required to configure the Sentinel IDP. If the on-premises application does not have an authentication mechanism, the vendor can provide a portal or other solution for retrieving an offline token as a one-time step.
Application Context	Sentinel	Client Credentials	The on-premises application communicates with the vendor application's back-end service, which consumes the Sentinel APIs and uses the client credentials flow.
Application Context	Vendor	Client Credentials	The on-premises application communicates with the vendor application's back-end service, which consumes the Sentinel APIs and uses the client credentials flow.