Set cookie step

A step in the Journey builder is a component used to configure and customize a login, registration, or self-service workflow.

The Set Cookie step allows the journey to create and manage cookies directly within the browser context. It can generate a cookie using data from a ative claim, local variable, or context variable (see Environment variables. The cookie can store important session data or other information that may be used in future interactions with the customer.

The cookie will be set when the first HTTP response is sent back to the browser after the journey has completed, ensuring the cookie is available for subsequent interactions.

Capabilities

• Dynamic cookie creation: You can create cookies dynamically by using data from native claims, local variables, or context variables. This enables you to generate cookies based on customer-specific data or session information, providing flexibility in how cookies are used during the journey.
• Session continuity: By utilizing cookies, you can ensure that session data is carried forward as the user progresses through various journey stages, allowing for a smoother, more consistent user experience across multiple interactions.
• Control over cookie behavior: The Set Cookie step provides granular control over how cookies are managed during the journey. You can specify attributes such as the cookie's expiration time, domain, and path, giving you flexibility in determining where and how the cookie is applied.
• Enhanced security features: The Set Cookie step supports important security features like HttpOnly, SameSite, and Secure attributes. These allow you to control when and how cookies are accessible, helping to protect against common web vulnerabilities such as cross-site scripting (XSS) and cross-site request forgery (CSRF).

Sample use cases

Dropping a cookie during a customer journey can be useful for many CIAM use cases, especially when trying to integrate with other products inside or adjacent to the CIAM ecosystem.

Some sample use cases include:

• Tracking browser-specific state or settings: Store settings or session-specific data in a cookie that customer extensions or platform integrations can use.
• Providing customer information to third-party systems: Pass customer data to third-party tools, such as analytics packages, by setting cookies with relevant information.
• Interfacing with legacy authentication systems: Seamlessly work with legacy systems, like Siteminder, that rely on specific cookies for authentication or session management.

Configuration

1. Access the Journey Builder:
   • Select the Journey Builder in the left-hand menu on the admin console.
2. Create or open a journey:
   • To create a new journey, select +Create journey or select an existing journey to edit.
3. Add the Set Cookie step:
   • In the journey builder, select the + icon in the upper left-hand corner to add a new step to the journey. Choose Set Cookie from the available options.
4. Configure the step:
   • By selecting the step module and the pencil icon, you can configure the cookie to be added.

When adding or editing this step, the following options can be configured:

1. Name: This optional field allows you to give a name to this specific journey step, which can help identify it in complex workflows. This name does not affect the cookie itself.
2. Cookie Name: The name of the cookie that will be set. You can choose from:
   1. Static value: Enter a predefined name.
   2. Native claim: Select a claim from the identity store to use as the cookie name.
   3. Local variable: Choose a journey-specific variable.
   4. Context variable: Select from available context data in the journey.
      Example: You might use a native claim like email or a local variable like session_id to define the cookie name dynamically.
3. Cookie Value: The value that will be assigned to the cookie. You can choose from:
   1. Static value: Enter a fixed value for the cookie.
   2. Native claim: Use customer-specific data from the identity store.
   3. Local variable: Pass a value from a previous step in the journey.
   4. Context variable: Use data related to the session or journey context.
      Example: You might set the cookie value to a user’s customer_id or a session token retrieved from a local variable.
4. Domain: Override the host to which the cookie will be sent. If left empty, the cookie will default to the domain from which the request originated. Use this if you want the cookie to be accessible across subdomains or specific domains.
5. Path: This defines the path within the domain where the cookie is valid. If a request doesn’t match the path, the browser will not send the cookie. If left empty, the path is not defined, meaning the cookie applies to the entire domain.
6. Max-Age: Max-Age specifies the number of seconds until the cookie expires. A value of zero or negative will expire the cookie immediately. If left empty, no expiration is defined, and the cookie will expire at the end of the session (a session cookie).
7. SameSite: SameSite controls whether the cookie is sent with cross-site requests, which helps prevent certain security vulnerabilities like CSRF. Options are:
   1. Do not define: No SameSite attribute is set.
   2. Strict: The cookie is only sent in a first-party context.
   3. Lax: The cookie is sent with first-party requests and some safe cross-site requests.
   4. None: The cookie is sent with all cross-site requests.
8. HttpOnly: Enabling HttpOnly prevents JavaScript from accessing the cookie, enhancing security by protecting against client-side attacks like XSS.
9. Secure: Enabling Secure ensures that the cookie is only sent over HTTPS connections, adding an extra layer of security by preventing the cookie from being transmitted over insecure HTTP.