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
Public Application	An application that cannot securely store credentials, such as client secret. These clients are typically executed in environments where their code or run-time is accessible to end users, making it impossible to ensure the confidentiality of sensitive information. Therefore, public clients do not authenticate themselves with the authorization server. Instead, they rely on other mechanisms, such as Proof Key for Code Exchange (PKCE), to enhance security during the authorization process." Public applications can be of the following types: >Single-Page Application (SPA). An SPA operates entirely within the browser after the source code is loaded from a web page. Since the source code is fully accessible through the browser, an SPA cannot store a client secret securely. Therefore, instead of using a client secret, an SPA uses a PKCE (Proof Key for Code Exchange) extension, which safeguards the authorization code during the redirect process. >On-premises application. An on-premises application cannot securely store a client secret and is, therefore, also considered a public client. The run-time environment of an on-premises application is accessible to the end user, which makes it susceptible to unauthorized access to sensitive information such as client secrets.To mitigate this limitation, an on-premises application should use a PKCE (Proof Key for Code Exchange) extension in conjunction with the Authorization Code Grant Type Flow. PKCE adds an additional layer of security by protecting the authorization code during the exchange process, ensuring that the application can securely obtain access tokens without relying on a client secret.
Confidential Application	An application that can securely store credentials, such as a client secret. These clients are typically deployed in environments where their code and storage are not accessible to end users, ensuring that sensitive information remains protected. Confidential clients authenticate themselves with the authorization server using their client credentials, making them more secure than public clients. Confidential applications include: 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.

Application Type

Description

Public Application

An application that cannot securely store credentials, such as client secret. These clients are typically executed in environments where their code or run-time is accessible to end users, making it impossible to ensure the confidentiality of sensitive information.

Therefore, public clients do not authenticate themselves with the authorization server. Instead, they rely on other mechanisms, such as Proof Key for Code Exchange (PKCE), to enhance security during the authorization process."

Public applications can be of the following types:

>Single-Page Application (SPA). An SPA operates entirely within the browser after the source code is loaded from a web page. Since the source code is fully accessible through the browser, an SPA cannot store a client secret securely. Therefore, instead of using a client secret, an SPA uses a PKCE (Proof Key for Code Exchange) extension, which safeguards the authorization code during the redirect process.

>On-premises application. An on-premises application cannot securely store a client secret and is, therefore, also considered a public client. The run-time environment of an on-premises application is accessible to the end user, which makes it susceptible to unauthorized access to sensitive information such as client secrets.To mitigate this limitation, an on-premises application should use a PKCE (Proof Key for Code Exchange) extension in conjunction with the Authorization Code Grant Type Flow. PKCE adds an additional layer of security by protecting the authorization code during the exchange process, ensuring that the application can securely obtain access tokens without relying on a client secret.

Confidential Application

An application that can securely store credentials, such as a client secret. These clients are typically deployed in environments where their code and storage are not accessible to end users, ensuring that sensitive information remains protected. Confidential clients authenticate themselves with the authorization server using their client credentials, making them more secure than public clients.

Confidential applications include:

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.

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.