Getting to Know the Enhancements and Features

Introduction to the One Account Model

When creating a new site, after selecting your data centers, you will now see a new prompt: "Select an Account Model". Here, you must choose between the "One Account" model or the existing "Legacy" model.

• One Account Model

  All users in your site, regardless of their registration status, will be managed under a unified account. This eliminates the need for complex migrations or merging when users upgrade from a lite account to a full account.

• Legacy Account Model

  Continues the prior behavior where lite accounts and fully registered accounts are separate entities, requiring additional migration steps if a user transitions to full registration.

Before selecting an account model, it is crucial to understand the following restrictions:

• Irreversible Choice

  Once chosen, the account model for a site cannot be changed.

• Model Isolation

  Sites and site groups cannot mix account model types; all child sites must inherit the parent’s account model.

• Site Group Consistency

  You cannot add a site with a different account model to an existing site group.

To make administration easier, the Admin Console now displays an "Account Model" column in the Sites→Site Selector screen. This column indicates whether each site is using the One Account or Legacy Account model, providing at-a-glance insight into your sites’ configurations.

With the One Account Model, managing unauthenticated user interactions has become easier with the new Guest Interaction Screen. This feature simplifies the onboarding process for users who wish to subscribe to content or receive notifications without immediate registration.

The Guest Interaction Screen, which is part of the Communications screen-set, can be found in the Default collection or any custom screen-set collections created after the One Account feature's release. Its internal name is Guest Interaction, identified by the Screen ID: gigya-guest-interaction-screen.

• Simplified User Experience

  Users can receive communications or subscribe to content without immediate registration.

• Unified Account Management

  All user interactions—authenticated or not—are linked to a single account, reducing administrative overhead.

• Easy Administration

  Manage guest interactions efficiently via the Guest tab in the User Access section of the SAP Customer Data Cloud admin console.

  

The Lite Preferences Center (Legacy) is a streamlined user flow that allows "lite" users to manage their communication and privacy preferences. This flow is initiated via a secure, single-use email invitation, ensuring simplicity and security for users without full account profiles.

The process begins with your website or application calling the `accounts.sendLiteInvite` API, which sends a personalized email with a unique, single-use link to the lite user. This link, protected by a single-use token (`regToken`), redirects the user to a dedicated Lite Preferences Center page on your site, where they can manage their preferences.

There are two primary ways to enable this feature:

• Via API

  Use the `accounts.setPolicies` API, passing the `preferencesCenter` object with a valid redirect URL.

• Via Console

  In the SAP Customer Data Cloud Console, navigate to the Email Templates menu under User Interfacing, open the Lite Preferences Center template, and set your redirect URL.

  

The One Account – Preferences Center offers a modernized and unified experience for users to manage their communication, data, and privacy settings from a single, secure location. This feature is accessed via a secure link sent to the user, which can be delivered by email, SMS, WhatsApp, or any preferred communication channel.

• Automated Email

  Use the `accounts.prefCenter.sendEmail` API to generate and send the email with the link.

• Custom Messaging

  Use the `accounts.prefCenter.getLink` API to generate the link, then include it in your own custom message (SMS, WhatsApp, etc.).

• Hosted Page

  Quickly deploy a Preferences Center by creating a Hosted Page of type Preference Center within SAP Customer Data Cloud. This is ideal for rapid setup and standard use cases.

• Custom Page

  For a fully branded and customized user experience, create a dedicated page on your website. This page must load the SAP CDC Web SDK (gigya.js) and invoke `accounts.showScreenSet` with a screen-set tailored for preferences management.

• Invitation

  The user receives a secure link to the Preferences Center by email or another channel.

• Access

  Clicking the link opens the Preferences Center page, where the SAP CDC Web SDK validates the session token.

• Management

  The user can view and update their communication, data, and privacy settings. All changes are saved in real time, ensuring compliance and user satisfaction.

• Unified Experience

  All user preferences are brought into a single, consistent interface.

• Flexible Delivery

  Send links via email, SMS, WhatsApp, or custom channels.

• Security

  Access is protected by expirable session tokens, reducing the risk of unauthorized access.

• Customization

  Choose between a quick Hosted Page or a fully branded custom implementation.

Linking Communications and Subscriptions to Consent Statements

• Automatic Synchronization of Consent and Communications

  Opt-Out Automation: Whenever a user withdraws consent from a mapped consent statement, they are automatically opted out of all linked communication topics and subscriptions—no manual processing needed.

  Integration: For those using SAP Customer Data Cloud Emarsys Integration, withdrawals are immediately communicated to Emarsys, ensuring users are removed from all pertinent communication streams.

• Flexible and Scalable Mapping

  Multiple-to-One Mapping: Many communication topics or subscriptions can be connected to a single consent statement. This supports scalable management when the same consent governs several content areas.

  One-to-One Restriction: Each individual communication topic or subscription can only be linked to one consent statement at a time.

• One-Way Linkage

  Directionality: Withdrawing from a mapped consent statement triggers opt-outs from all linked subscriptions and communications. However, opting out from a subscription does not withdraw the consent itself.

  Subscription Behavior: Users may opt in to a subscription even if the mapped consent is not currently granted.

  Linking is always performed from the Subscriptions or Communications UI—not from the Consent Statements interface itself.

• Version Requirement

  Consent v2 Required: Linking subscriptions or communications is available only to customers who have migrated to Consent v2. This ensures compatibility with the updated consent management infrastructure.

Introducing Token Exchange Support for SAP Customer Data Cloud Tokens

• Granular Token Control

  Developers can exchange existing tokens for new tokens with adjusted scopes and audiences. This means that applications and services can obtain only the permissions they require—no more, no less—supporting the principle of least privilege.

• Security and Flexibility

  Instead of distributing and managing multiple high-privilege tokens, developers can now down-scope tokens for safer use or up-scope tokens for specific application needs, depending on the scenario.

• Better Integration

  Enterprises often use several APIs or back-end systems, each needing tokens with specific claims. The token exchange feature is especially useful for:

  • Web or mobile apps obtaining limited-permission tokens for downstream APIs
  • Services, middle-ware, or AI agents securely calling SAP Customer Data Cloud APIs on the user’s behalf
• Reduced Attack Surface

  By exchanging tokens for new, short-lived, and narrowly-scoped tokens, organizations minimize risk and improve compliance with security policies.

The new /token endpoint now supports the following grant_type values:

• authorization_code
• client_credentials
• refresh_token
• jwt-bearer
• urn:ietf:params:oauth:grant-type:token-exchange

The token-exchange grant type is only supported for exchanging SAP Customer Data Cloud tokens for other SAP Customer Data Cloud tokens.

1. Client Request:

   The client sends a POST request to /oidc/op/v1.0/{{apiKey}}/token with the grant type set to urn:ietf:params:oauth:grant-type:token-exchange.

2. Request Parameters:

   The request must include:

   • subject_token: The original token to be exchanged (access token or ID token).
   • subject_token_type: The type of the original token.
   • requested_token_type: The desired output token type (access token or ID token).
   • Optional parameters: audience, scope, etc., to further tailor the resulting token.
3. Token Validation:

   SAP Customer Data Cloud validates the input token and applied security policies.

4. Token Issuance:

   If all checks pass, a new token is issued with the requested type, claims, and scopes.

5. Issuer Restriction:

   Only tokens originally issued by the SAP Customer Data Cloud OIDC OP can be exchanged.

To maintain strong security for token exchange:

• Prefer issuing short-lived exchanged tokens to minimize misuse.
• Enforce strict audience restrictions to prevent token replay across services.
• Down-scope permissions wherever possible for each use case.
• Follow all security best practices from RFC 8693 and other OpenID Connect standards.

Introducing OIDC Support for Admin Console Login

Administrators can now configure the OIDC Console Login directly from the admin console. The setup process is accessed via Administration→Access Management→Federated Console Login→OIDC Console Login. Here, administrators connect their corporate OIDC OP with SAP Customer Data Cloud, ensuring that all admin login attempts are verified against centralized identity policies.

• Login URL:

  Define a custom login URL for your organization’s admin console. This subdomain must be unique within your Primary Data Center and should only contain lower-case letters and numbers. Using upper-case letters, even though the UI allows it, will disrupt the login flow due to lower-case enforced redirects.

• Issuer:

  Specify the issuer value as configured in your OIDC OP.

• Client ID and Client Secret:

  Enter the client_id and client_secret specific to the SAP Customer Data Cloud administration console.

• Provider Endpoints:

  Input endpoint URLs provided in the well-known metadata of your OP for:

  • authorize (authorization endpoint)
  • token (token endpoint)
  • userinfo (user information endpoint)
  • jwks (JSON Web Key Set endpoint)

• Scopes:

  Select or define the required scopes for admin authentication, including any custom scopes as needed.

• Client Authentication Method:

  Choose from client_secret_basic, client_secret_post, or None. If None is chosen, Proof Key for Code Exchange (PKCE) must be enabled.

• Enable PKCE:

  Enabling PKCE is strongly recommended to mitigate authorization code interception attacks. This is mandatory if no client authentication method is chosen. PKCE is recommended for public clients and browser-based applications.

• SAP Customer Data Cloud TFA:

  Decide if Two-Factor Authentication (TFA) will be enforced by the admin console or by your OP. TFA must always be enforced for console access.

• Finalize Login URL:

  Register this URL as the Authorized Redirect URI in your OP’s RP client configuration.

You can control administrator permissions within the console or via claims passed in the access token from your OP. If you choose to manage permissions in the console, create a dedicated permissions group for OIDC-authenticated admins and assign it as the default. Failure to do so, or assignment to the _no_permissions group, will prevent admins from accessing the console after login.

Enhanced Email Template Branding with CNAME Support

For organizations not leveraging screen-sets for password management, there is now greater flexibility in how password reset flows are handled. You should define a dedicated URL for your password reset page. When users request a password reset, the system sends an email containing a reset link that directs them to your specified reset page. By default, SAP Customer Data Cloud provides a reset page at:

• https://<yourCNAME>/newPassword (when a CNAME is configured)
• https://socialize.gigya.com/newPassword (if no CNAME is set)

You may also configure a custom URL for your reset page to better align with your brand or user journey. The reset link variable, $pwResetLink, is dynamically composed based on your CNAME site settings and includes the $pwResetToken for secure password reset operations.

Private Key Version Selection for Key-Pair Generation

HIBP Integration for Compromised Password Detection

When this feature is enabled, SAP Customer Data Cloud checks user-submitted passwords against the HIBP database. If a password appears in the database (meaning it has been exposed in a previous data breach), the system will reject it and prompt the user to choose a different password. This reduces the risk of account takeover and credential stuffing attacks, which are often the result of users reusing breached passwords.

• Real-time Detection:

  Passwords are validated against the HIBP public breach database during password reset and account update operations.

• Automatic Blocking:

  Attempts to reset or update passwords with known compromised entries are blocked, and users receive a clear error message.

• User Guidance:

  The system provides informative feedback, such as:"The entered password was detected as having been compromised. Please enter a different password and try again."

• Simple Configuration:

  Enable or disable HIBP verification for password resets via the admin console, under Identity→Security→Authentication→Password Settings.

  Once enabled, any attempt to use a compromised password during reset or update will be blocked, and users will be prompted to try a different password. If the password has not been compromised, the process will proceed as normal.

• Privacy Protection:

  Password checks are performed using hashed values, ensuring plain text passwords are never sent to third-party services.

OAuth Authentication for Webhooks

When subscribing to events or configuring webhooks, you can now enable OAuth authentication by providing the necessary OAuth configuration parameters. This is done using a JSON object named oauthConfig, which contains the authentication information required to obtain an access token from your OAuth provider.

• tokenEndpointUrl: The endpoint where the OAuth token is requested.
• clientId: The client identifier registered with your OAuth provider.
• clientSecret: The secret associated with your client ID.

• scopes: Specifies the OAuth scopes to request. Multiple scopes can be included, separated by spaces (e.g., "openid profile email address phone").
• audience: Allows you to specify a particular audience for the access token if needed.

To retrieve an OAuth token using the client credentials grant, you might use the following cURL command:

1234567
curl -X POST https://auth.example.com/oauth2/token \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -d "grant_type=client_credentials" \
     -d "client_id=my-client-id" \
     -d "client_secret=my-client-secret" \
     -d "scopes=scope1 scope2"

By implementing OAuth authentication for webhooks, you ensure only authorized systems can receive sensitive event data from SAP Customer Data Cloud, providing a more robust integration framework.

Group Data Mapping for OIDC

• Expanded Claim Mapping:

  You can map custom claims not only to standard account fields (such as profile and data) but also to:

  • Group and relationship data
  • Custom identifiers
  • B2B organization data (with the exception of samlData)

• Custom Scopes and Claims:

  Before defining a custom scope, you must first specify the claims to be included. Each claim can be mapped to any of the eligible account fields listed above.

• Scope and Claim Constraints:
  • You may define new custom scopes and associate them with your mapped claims as needed.
  • Default OIDC scopes cannot be overwritten.
  • Both scope and claim names are case-sensitive and must not contain spaces.

This expanded flexibility in mapping group and relationship data makes it easier for organizations to ensure that their OIDC tokens carry exactly the information needed for downstream applications—improving security, efficiency, and integration control.

Custom HTTP Header Validation for Unsigned API Calls

When enabled, administrators can specify one or more custom HTTP headers that must be included in every unsigned API request. Any incoming unsigned API request that lacks the required headers will be automatically rejected by the system, helping to ensure that only trusted sources—those configured to include the appropriate headers—can interact with your SAP Customer Data Cloud environment.

• Block Unauthorized Requests:

  Any unsigned API request missing the defined custom headers will be rejected with error code 400001.

• Customizable Security:

  Administrators can define a list of required headers, either custom or from presets such as Akamai or Shape.

• Granular Configuration:

  Header validation can be set up at either the site or site group level, allowing for flexible security policies.

• Easy Administration:

  Configuration is managed through the admin console under Identity→Security→Header Validation .

This feature helps prevent spoofed, malformed, or otherwise unauthorized unsigned API requests from reaching your systems, ensuring that only requests with the correct headers are processed.

Introducing Enhanced OIDC Claims and Business Entity Mapping for B2B

• Business Entity Data in OIDC Claims

  You can now map Business Entity data directly into OIDC claims during just-in-time provisioning. This means that when a user is provisioned, their associated business entities are included in the claims, enhancing downstream authorization and personalization.

• Centralized OIDC Configuration for B2B

  OIDC for B2B is now managed from the main SAP Customer Data Cloud application, alongside other OIDC Relying Parties (RPs). When CIAM for B2B is enabled, you’ll notice a new dropdown in the RP configuration screen. This allows you to link the RP to a specific B2B application by selecting it from your list of existing B2B applications.

• Expanded Claim Mapping Options

  Linking an RP to a B2B application unlocks advanced claim mapping. You can now map not only Organization and Authorization data, but also Business Entity data. These mappings can be added to custom scopes within the OIDC OP settings, giving you granular control over what information is shared.

• Flexible Business Entity Mapping

  All business entities assigned to a user are mapped by default. For more targeted mapping, you can specify a single Business Entity Type by entering b2b.auth.businessEntities.[businessEntityTypeName] in the claim field.

  Note

  Business entity types with spaces in their names are not supported for mapping.
• Identifying the B2B AppId

  Each B2B application is linked to an AppId, which is required for correct OIDC OP association. Find the AppId in the ClientID field under the Applications tab of the Organization Management console.

Enhanced Account Import: Email Policies No Longer Block Imports

• Import Flexibility:

  Both verified and unverified emails can be included in imports, regardless of active email verification policies.

• No Emails Sent During Import:

  When email policies are active during the import, users will not receive automated emails as part of the process. This applies to any automated email policy configured on your site.

• Policy Management Tip:

  If you want to ensure that imported users never receive emails triggered by the import, it’s best practice to turn off automated email policies before starting the import.

Introducing RP-Initiated Logout for OIDC OPs

• RP-Initiated Logout Capability

  RPs can now trigger a logout request at the OIDC OP, allowing users to be signed out from both the current RP and the OIDC OP in one step. This mechanism can also propagate logout across all connected OIDC client applications, enhancing both user convenience and security.

• Enhanced User Experience & Security
  • When an end user logs out from an RP, they are given the option to log out from just the RP or from the OIDC OP and all associated RPs.
  • The process is compliant with the OpenID Connect RP-Initiated Logout 1.0 specification and leverages the end_session_endpoint for session termination and cleanup.
• Customizable Logout Flow
  • After logout, users can be redirected to a post-logout landing page (Trusted Post Logout URL), improving navigation and clarity.
  • The flow supports both front-channel and back-channel logout propagation.
• Implementation Essentials
  • Screen-Sets:

    To use this feature, generate a new Screen-Set Collection via the UI Builder. Two new screens are included:

    • Confirm Logout (gigya-logout-screen): For logging out from only the current RP.
    • Consent Logout(gigya-consent-logout-screen): For logging out from the OIDC OP and all connected RPs.

  • Hosted Pages:

    If using Hosted Pages, create a new page of type ‘Logout’ and configure it with the new screen-set collection.

  • Logout URLs:

    Set the Logout Page URL in the OIDC OP settings and configure Trusted Post Logout URLs in the RP configuration. At least one Trusted Post Logout URL must be set as the default.

• Prerequisites for RP-Initiated Logout
  • The RP must use an SAP Customer Data Cloud OIDC OP with the end_session_endpoint available.
  • The OIDC OP must have a valid authorized Post Logout Redirect URI for the RP.
  • The user must have an active session with the OIDC OP.
  • The logout request must include the id_token_hint (the current id_token of the user).
• Standard Logout Flow
  1. User initiates logout from the RP.
  2. The RP sends a request to the end_session_endpoint with required parameters.
  3. The OP presents logout options to the user.
  4. The user chooses to log out from only the RP or from all connected applications.
  5. The user is redirected to the specified Trusted Post Logout URL upon completion.

Introduction to New Web SDK Features and Functionalities

Security Enhancement:

• Non-Eval SDK Option:

  By enabling the toggle for the non-eval version of the Web SDK, you can load the SDK without requiring ‘unsafe-eval’ in your CSP. However, this may restrict some existing features and require updates to your current implementation.

• Global CONF Object Deprecation:

  If your site relies on a global CONF object defined within the script tag that loads gigya.js, gigya.saml.js, or gigya.oidc.js, this object will now be ignored. You must remove any in-line CONF object from your script tags and, if necessary, define the required properties in a local JavaScript object instead.

• Loss of String Interpolation:

  String interpolation inside screen-sets—such as using {{schema.preferencesSchema.fields[...]}} to propagate user data—will no longer function with the non-eval SDK. You must update any screens that use this feature before enabling the toggle.

• In-Page Screen-Set Integration Change:

  The previous method of copying HTML screen-sets from the Advanced Customization window in the UI Builder and pasting them directly into your website will no longer work. When using the non-eval SDK, screen-sets must now be loaded from the server. Existing copy/paste implementations must be updated.

• UI Builder Preview Mode Limitation:

  The UI Builder’s Preview mode will continue to use the eval-enabled SDK, regardless of the toggle’s setting. This may cause differences between how screens appear in the UI Builder and how they render on your live site. It is essential to test all screens on your actual website to ensure correct behavior before deploying to production.

Introducing Internal Fields Support in importFullAccount

Internal fields are data attributes linked to a user that are not included in the user's public account data. These fields are intended for back-end processes and are exclusively accessible during server-to-server API calls—meaning they are never exposed to the user or external systems via public endpoints.

Organizations can now import and manage sensitive or operational metadata alongside users, such as audit flags or back-end status indicators, without risking exposure through public APIs or user interfaces.

When calling the accounts.importFullAccount REST API, you can now pass an internal object as part of the user record payload. Here’s a simplified code example:

123456
{
  "internal": {
    "test_read": "done2"
  }
}

This new support streamlines the process of maintaining and importing behind-the-scenes data attributes for users, improving integration flexibility and data governance.