Name: Configuring JSON Web Token (JWT) in SAP Customer Data Cloud
Uploaded: 2024-8-12
Duration: 318 s
Description: In this video, you will learn about the JSON Web Token (JWT) and how it is used in SAP Customer Data Cloud APIs. Specifically, you will learn how to get JWT from Customer Data Cloud as well as how to validate JWT.

Share feedback

<p><u><strong>Planned maintenance of Practice Systems</strong></u></p>

Planned maintenance of Practice Systems

Why create an SAP account?

Enhance your learning experience

SAP Learning

Choose your subscription

Manage your subscription

Live Sessions

Hands-on Practice

Certification

My Learning

Ready to start learning?

<div><div><div><div><div><div><div>In this video, you will learn about the JSON Web Token (JWT) and how it is used in SAP Customer Data Cloud APIs. Specifically, you will learn how to get JWT from Customer Data Cloud as well as how to validate JWT. </div></div></div></div></div></div></div>

Configuring JSON Web Token (JWT) in SAP Customer Data Cloud

In this video we will see what JWT is, and how it is used in SAP Customer Data Cloud APIs. Specifically, we’ll see how to get JWT from Customer Data Cloud and validate JWT. JWT or “jot” stands for JSON Web Token. It is an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. SAP Customer Data Cloud currently supports generating a JWT on the client SDK and REST API. The Client JWT can be requested only after the user is authenticated, as the Customer Data Cloud SDK internally uses the UID of the logged in user to get the JWT. Common use cases where JWT is implemented are an IoT and server-to-server trustless environment. JWT is also a great option for integration scenarios. Let’s look at an example scenario.  In this scenario the user wants to access trusted claims from a server. To achieve this, the users authenticate themselves by entering their credentials and Customer Data Cloud authenticates the user. Once the user is authenticated, the client requests for JWT from the CDC. With JWT, the client requests trusted claims from the server. The server asks for the public key from CDC and the validated JWT. Once the token is validated, and the user can access trusted claims from the server until the JWT expires. Now, let’s see this flow in action. The user logs in to the client application. Once the user is authenticated, the client application requests the JWT from the Customer Data Cloud. The id_token received from CDC is a valid JWT that consists of 3 parts.  To check the decoded JWT body: Open jwt.io and past the encoded token. You can see that the token consists of 3 parts: Header, Body, and Signature. To validate the authenticity of the JWT, you must compare the header plus payload against the signature using the originating site’s public key. We requested the JWT by making a call to the accounts.getJWT API of the Customer Data Cloud. In this demo, we are using the Customer Data Cloud’s Web SDK. This is what the code should look like. Include the web sdk in the html file and pass the API key. Call the getJWT api by passing parameters as an object. In this request, we are requesting some additional fields. You can only make a call to this API after successful authentication.  Next, let’s get the public key from the Customer Data Cloud. You need public key to validate the JWT. Out of the various details received as part of the response, only two values are used in this demo: Modulus: A base64url encoding of the returned id_token. And the exponent value for the RSA public key, base64url encoded. To get the public key from the Customer Data Cloud, the server calls the accounts.getJWTPublicKey API. This API can’t be called from the client SDK. In this demo we are using the PHP Server SDK. There are several key points to note in this code: Include GSSDK.php in your code. Pass the API Key, and Secret. If you are passing the User or Application Key as well, the Secret should be for the User or Application Key. The GSRequest function creates the request. Add additional parameters to the request if needed. In this example, we are passing the datacenter. The last step is to validate the JWT with the Public Key. For this, you must compare the header + payload against the signature using the originating site’s public key. The "validate id_token" button does exactly the same. As you can see, the JWT we received from Customer Data Cloud is a valid token. Let's see the code which runs behind the scenes.  We can validate the token on both the client or server side. For this demo, we have written a php code to perform the validation.  As seen earlier, the three parts of the JWT are separated by a decimal point; The code first splits JWT into three parts based on this.  Then combines header + payload. Sanitizes and Base64 decodes the signature, modulus and exponent. Sanitize means replace '-' to '_'  and '+' with '/'. Then verify the token data with the signature. And that ends the JWT demo. Thanks for watching.