SAP Customer Data Cloud Positions

Security Best Practices

Skip to end of metadata
Go to start of metadata


The SAP Customer Data platform is designed to provide maximum security for your critical data. Please follow the guidelines provided in this document to make sure you are leveraging all the security features built into the platform.

When using any REST API that transmits sensitive data, e.g., passwords or secrets,  recommended best practice is to always use POST requests via an SSL secured connection. When using any Gigya APIs, attempting to send a secret over a non-SSL connection will result in an errorCode: 403006 - Secret Sent Over Http.

Secure Communication


The SAP Customer Data Web SDKREST API and SDKs API calls must be made over HTTPS (SSL). Using HTTPS ensures that no one can eavesdrop on the data passed between the server and your user's browser. You can only use HTTPS with SAP Customer Data Gigya APIs.

When using an HTTPS domain, when loading the Gigya Web SDK on a web page, load it from our HTTPS domain (i.e., reference "CDNS" and not "CDN", as per the example below). This will not only load the SDK itself over HTTPS but will cause the SDK to perform all its communications with the Gigya server over HTTPS as well.
As a reminder, every page that uses the Gigya API must load Gigya's Web SDK in the <HEAD> section (refer to Getting Started for the complete guide). On secured pages, the line of code should be:
<script src="" ></script>

Secure Protocols

For security reasons, SAP Customer Data only supports TLS protocols 1.2 and above, with specific ciphers. These ciphers may change as we regularly update the platform to new security standards, so please follow our Changes That May Require Your Action page. 

Supported Ciphers: 













Custom API Domain

Use a custom API domain to route SAP Customer Data Cloud traffic through your domain, instead of through the various "" domains (e.g. calls will go through instead of Otherwise, some browsers or browser settings may block Gigya calls as they are considered 3rd-party. Your custom API domain is configured on the site settings page of the Console. For more information, see Blocked Third-Party Cookies and Site Setup.


Certificate Provisioning

For the same reason, as well as to support some single sign-on scenarios, we recommend you use Certificate Provisioning on your site.


Validate the Session in a Login Process

After a user completes a login successfully (using any of our supported authentication options such as site, social, phone number, OIDC), it is not enough to intercept the onLogin event fired by Gigya: you should also validate the user's session and the UID. Otherwise, malicious attacks may be made masquerading as a logged in user. Validation is done using an id-token JWT. To receive the id-token from the onLogin events, be sure to add "id-token" to the include parameter of your Global Configuration. A sample id-token: 

    "current_id_token_data_json_header": {
        "typ": "JWT",
        "alg": "RS256",
        "kid": "{keyId}",
        "dc": "{datacenter}"
    "current_id_token_data_json_body": {
        "iss": "{Gigya/CDC-API-key}/",
        "sub": "String (User's Gigya/CDC UID)",
        "iat": "Integer (Current UTC)",
        "exp": "Integer (Current UTC+60 sec)",
        "isLoggedIn": "Boolean //(ALWAYS FALSE FOR SERVER CALLS)"


The id-token: 

  • Is used to validate that the user has an active client session with Gigya.
  • Is a short-lived JWT that holds the UID of the user.
  • Does not hold any PII data, and is safe to transfer to 3rd parties.
  • Is not treated as a session, just a proof of ownership.

Our best practice recommendations: 

  • Always prefer to use a standard library for validation, as opposed to writing your own

  • Validate the signature with our public JWT by calling accounts.getJWTPublicKey with V2 set to 'true'.

  • Validate the issuer against your site's API key

  • Validate the expiration of the token
  • Validate that isLoggedIn is 'true' before returning a session to the client to confirm the user is actually logged in to SAP Customer Data (as opposed to pending registration for instance)


Sample code for validating an id-token

private async Task<string> ValidateJWT(string idToken)
            var httpClient = new HttpClient();
            var response = await httpClient.GetStringAsync($"");
            var jwks = new JsonWebKeySet(response);
            var parameters = new TokenValidationParameters
                ValidateAudience = false,
                ValidateIssuer = true,
                ValidIssuer = $"{apikey}/",
                ValidateLifetime = true,
                IssuerSigningKeys = jwks.Keys
            var handler = new JwtSecurityTokenHandler();
            SecurityToken jwt;
            ClaimsPrincipal claimsPrincipal = handler.ValidateToken(idToken, parameters, out jwt);
            var uid = claimsPrincipal.FindFirst("sub").Value;
            return uid;


Get Verified User Data with a Server-Side Call

After establishing that the user has an active Gigya session, you may still not trust all the user data sent directly to your servers from the client - as data fields, like the user name or email address, may be sent from a tampered source. If your application relies on receiving verified data from the provider, make a server-side REST API call to Gigya to retrieve that data. Learn more about Using the REST API.

Signing REST API Calls

REST API requests to Customer Data Cloud should be made securely, using an authentication mechanism. The recommended method is to use a bearer token, constructed using a unique RSA key provided on the SAP Customer Data Cloud console. The RSA private key creates a short-lived one-time token for each call and protects your requests from replay attacks or theft of your user secret.  

Another way is to use an application key and secret (or user key and secret). This is true also for requests made on your behalf (using your API Key) by third parties. For more information, see Signing Requests to SAP Customer Data Cloud.

Verifying User Data With the Web SDK

When performing client-side calls, we recommend the following: 

  • When applicable, assigning "server-only" update permissions to more sensitive data fields, preventing any client-side update to these fields. Note that such fields cannot be updated using our Screen-Sets. For more information, see Schema Editor
  • When passing data client side, you can perform validations on that data by utilizing Extensions (for example, checking phone number or ZIP code formats). Use Extensions as a decision point for allowing or blocking a user action, such as registration or profile update, under certain conditions. 
  • SAP Customer Data Cloud does not sanitize field data provided by your end-users. We recommend sanitizing data based on OWASP best practices


Protect Your Keys

Your user and application keys, RSA keys and partner keys may be used to provide access to your application. Anyone who gains access to your SAP Customer Data credentials may pretend to be you and perform actions on your users on your behalf, therefore it is crucial to protect your keys. Take extra caution and never ever use the secret key on a client where malicious users could gain access to it. Do not use them on client-side implementations or store in plain text.  

General Note about Signatures

Remember that signatures contain binary data encoded using the BASE64 format. BASE64 format (as well as email addresses, etc.) uses characters that must be properly encoded when passed between the browser and the server or the signature verification will fail. Be sure to use encodeURIComponent() on all pertinent strings.


userKey=encodeURIComponent(userKey); // >> LV%2F24EGI7T%2Bxl

Additional Information

Special Information - Data Controllers

The Gigya platform does not include any technical measures that support the processing of Special Categories of Personal Data, which includes but is not limited to:

  • Racial or ethnic origin
  • Political opinions
  • Religious or philosophical beliefs
  • Trade-union membership
  • Health or sex life
  • Personal data concerning bank and credit accounts
  • Genetic data
  • Biometric data for the purpose of uniquely identifying a natural person