Sentinel EMS Workflow with OAuth Clients
|
>Client Credentials Grant Type Flow for Use with the Sentinel IDP >Authorization Code Grant Type Flow for Use with the Sentinel IDP >Authorization Code Grant Type Flow for Use with the Vendor IDP |
This page describes the various workflows that you can use when defining OAuth clients in Sentinel EMS and using OAuth with the Sentinel REST APIs. The Sentinel Identity Provider (IDP) is used either exclusively or partially in all of these flows.
Client Credentials Grant Type Flow for Use with the Sentinel IDP
In this service-to-service flow, the vendor's back-end service uses client credentials to request an access token on behalf of the application. This flow returns an access token with administrator privileges that enables your application to consume the Sentinel REST APIs. The client credentials grant type flow is relevant only for confidential OAuth clients.
Recommended for:
Server-side web applications, where the API is called on behalf of the application.
Prerequisites and Initial Setup
1.The vendor administrator must add an OAuth client using either the Sentinel EMS vendor portal (described in Adding an OAuth Client) or using the Sentinel EMS APIs.
2.After creating the OAuth client, the vendor administrator must retrieve the Client ID and Client Secret, and the Sentinel Identity Provider (IDP) endpoints from the Sentinel EMS vendor portal or using the Sentinel EMS APIs.
Client Credentials Flow: Implementation with the Sentinel IDP
1.The vendor's back-end service can fetch the client credentials from an environment variable, a secure location, or another service.
2.The vendor's back-end service must obtain the JWT from the Sentinel IDP using the client credential OAuth flow.
3.The vendor's back-end service consumes the Sentinel EMS REST API using JWT.
Best practices:
>Store client credentials securely.
>Optionally run periodic jobs from the vendor service to get new JWT before the JWT expire. For example, after 75% of the time has elapsed.
>Use a singleton class for access token handling. Ensure that token creation happens with synchronization to handle concurrent requests.
Authorization Code Grant Type Flow for Use with the Sentinel IDP
In this flow, the vendor uses the Sentinel IDP to authenticate users and to issue an access token that enables users to log in and use the vendor application. The main difference between this flow and Authorization Code Grant Type Flow for Use with the Vendor IDP is that only the Sentinel IDP is used, not the vendor IDP.
Recommended for:
>Server-side web applications, where the API is called on behalf of the user.
>Single-page applications, where the API is called on behalf of the end user. In this case, you must create an OAuth public client that uses the Authorization Code grant type with PKCE.
>On-premises applications, where the API is called on behalf of the end user. In this case, you must create an OAuth public client that uses the Authorization Code grant type with PKCE.
Prerequisites and Initial Setup
1.The vendor administrator must add an OAuth client using either the Sentinel EMS vendor portal (described in Adding an OAuth Client) or using the Sentinel EMS APIs.
2.After creating the OAuth client, the vendor administrator must retrieve the Client ID, Client Secret (for confidential clients only), and the Sentinel Identity Provider (IDP) endpoints from the Sentinel EMS vendor portal or using the Sentinel EMS APIs.
To ensure a seamless user experience when using the vendor application,
Authorization Code Grant Type Flow: Implementation with the Sentinel IDP
1.The vendor developer uses the authorization code flow when initiating the authentication process with the Sentinel IDP. End users see the login page from the Sentinel IDP, which is customized with the vendor's branding, and enter their login credentials for authentication purposes.
2.The vendor application must initiate the authentication workflow using the Sentinel IDP endpoint to fetch the Sentinel JWT for the logged-in user. The vendor application must obtain the Sentinel JWT for the logged in user, so that an access token can be generated for the Sentinel IDP.
3.After retrieving the access token, the application can consume the Sentinel REST APIs with the JWT for the user.
4.The application must store the JWT for the user for at least the open session. Make sure to refresh the access token before it expires. To ensure a seamless customer experience, you might refresh the token after 75% of the time has elapsed. You can also refresh the token when the token expires. The implementation depends on your application requirements.
Authorization Code Grant Type Flow for Use with the Vendor IDP
In this flow, the Sentinel IDP is configured with the vendor IDP details, so that users are authenticated using only the vendor IDP. This flow issues an access token that enables users to log in and use the vendor application.
To access Sentinel REST APIs, the vendor application uses a Sentinel JWT that was issued by the Sentinel IDP, as described in Authorization Code Grant Type Flow: Implementation with the Vendor IDP below.
The main difference between this flow and Authorization Code Grant Type Flow for Use with the Sentinel IDP is that both the vendor IDP and the Sentinel IDP are used. Additionally, the vendor developer must ensure that the Sentinel JWT for the user is issued by the Sentinel IDP prior to any Sentinel API calls.
Recommended for:
>Server-side web applications that authenticate users with the vendor IDP, where the API is called on behalf of the user.
>Single-page applications that authenticate users with the vendor IDP, where the API is called on behalf of the user. In this case, you must create an OAuth public client that uses the Authorization Code grant type with PKCE.
>On-premises applications that authenticate users with the vendor IDP, where the API is called on behalf of the user. In this case, you must create an OAuth public client that uses the Authorization Code grant type with PKCE.
Prerequisites and Initial Setup
1.The vendor IDP must be configured in Sentinel EMS for federation purposes. Contact Thales Customer Support to set up your vendor IDP for you.
2.Each application user that is provisioned in the vendor's system must also be provisioned (without a password) in Sentinel EMS. Make sure to use the same Sentinel EMS instance as the vendor IDP. For Sentinel EMS vendor users (not end users or channel partners), make sure to associate the required roles as well.
3.The vendor administrator must add an OAuth client using either the Sentinel EMS vendor portal (described in Adding an OAuth Client) or using the Sentinel EMS APIs. For Confidential Client Type applications, the vendor administrator must retrieve the Client ID and Client Secret after creating the OAuth client.
4.The vendor administrator retrieves the Sentinel Identity Provider (IDP) endpoints from the Sentinel EMS vendor portal or using the Sentinel EMS APIs.
Authorization Code Grant Type Flow: Implementation with the Vendor IDP
1.The vendor developer starts the authentication process with the vendor IDP. End users see the vendor application's login page and enter their login credentials for authentication purposes.
2.The vendor application must obtain the Sentinel JWT for the logged in user, so that an access token can be used to consume Sentinel REST APIs. To obtain the Sentinel JWT, you start the authorization code flow with the Sentinel IDP, which then redirects to the vendor IDP. You can start this flow wherever it is required in your application, not just when the user logs in. For example, if an area of your application requires data from a Sentinel REST API, you must initiate the flow before the Sentinel REST API call.
3.After retrieving the access token, the application can consume the REST API with the JWT for the user.
4.The application must store the JWT for the user for at least the open session. Make sure to refresh the access token before it expires. To ensure a seamless customer experience, you might refresh the token after 75% of the time has elapsed. You can also refresh the token when the token expires. The implementation depends on your application requirements.
Selecting an OAuth Grant Type
You can select a suitable OAuth Grant Type for your application by using the following flowchart. This flowchart outlines the decision-making process for selecting a grant type based on whether your application is public or confidential. Use this flowchart to determine the best grant type based on your specific requirements.
For details, see Client Type.
NOTE This flowchart is relevant only when using Sentinel REST APIs for Sentinel EMS and Licensing.
