Cross-Domain Cookie

Cross-domain cookie specification

Summary

In order to transfer a session across different platforms and create a seamless UX, cookies using a shared namespace and an encrypted payload are used. Once a visitor signs into their account, their authenticated session must be transferred/persisted between the separate web technologies (the website, the booking engine, and/or loyalty portal) to create a seamless user experience.

Use Cases

Scenario A: From main site.com, a visitor log's in.

  • Authentication is performed by calling upon a CRM web-service to fetch a loyalty profile by username and password.

  • Upon successful authentication, an encrypted cookie will be set on the domain .site.com and thus accessible by services running on sub-domains of "site.com". This cookie will contain a very limited amount of profile data (outlined below) in an encrypted format.

  • The IBE/loyalty program running from subdomains of site.com will be able to detect the presence of the encrypted cookie and start a server-side session to automatically facilitate logging the visitor in.

Scenario B: From the decoupled loyalty portal/IBE, a visitor logs in.

  • Upon successful authentication, the decoupled IBE/loyalty portal will start a server-side session.

  • Additionally, an encrypted cookie will be set on the domain .site.com and thus accessible for reading by the smartCMS (site.com) as well as the IBE/loyalty portal. This cookie will contain a very limited amount of profile data in an encrypted format. Cookie specifications are outlined below.

  • The website running from site.com will be able to detect the presence of the encrypted cookie and start a server-side session to automatically facilitate logging the visitor in.

Scenario C: From either site.com or the decoupled IBE and/or loyalty portal, a visitor logs out.

  • Upon logging out, a visitor's session should be destroyed. Additionally, the encrypted cookie should be deleted/expired so that both platforms perceive the visitor as logged out.

Cookie Specifications:

IV string is prepended to the cookie, please see the update section.

Cookie Name:

  • The name of the authentication cookie should be set to sessionTransfer

Cookie Domain:

  • The cookie must be set for the domain .site.com

Note the significance of the leading "." character

Contents:

  • The data stored within the cookie should be json format

Json Properties:

  • The json object should contain the following properties:

    • profileid - A unique identifier for the authenticated user

    • firstname - The first name of the authenticated visitor

    • lastname - The last name of the authenticated visitor

    • loginid – The loginId (email)

    • membernumber – membership number

    • membertier – membership level

    • salutation – member salutation

    • balance – member’s point balance

    • rememberme – flag for remember me

    • sessionexpiry – unix timestamp representing Now + 5 minutes.

      • The timestamp should be relative to the Unix epoch

    • (https://en.wikipedia.org/wiki/Unix_time) Both the website and the decoupled loyalty portal should validate against this field. The cookie’s information should only be utilized and acted upon when the ‘sessionexpiry’ timestamp has not yet passed. Otherwise, the visitor should be required to re-authenticate when browsing between the website and loyalty portal.

      • Having a static sessionexpiry:

        • A static sessionexpiry implies that neither platform would be responsible for “updating” the timestamp of the sessionexpiry once a value has been set during login. Thus, a user would be able to successfully transfer their session from one platform to the other within a 5-minute window after logging in.

Example

Json

{  
   "firstname":"Test",
   "lastname":"User",
   "profileid":10000001,
   "loginid":"[email protected]",
   "username":"[email protected]",
   "membernumber":"10000000001",
   "membertier":"MEMBER",
   "salutation":"Mr.",
   "balance":null,
   "rememberme":false,
   "lifetimeexpiry":636941639980000000,
   "sessionexpiry":636941639980000000
}

Resulting encrypted string

MmM1ODEwZjQwMDQ3NGVjMDdmYWQ0NGY5ZDBmZWIzZmXgjfGl1aw/TirfbYJHIl7WgGtpuHu8lkPccP2txTCdqS38Z5B/w+AKNQS0c+jZJiNw0aU7bNOrS/7/2Md0khUHAqmXyJjdCPTKy2IcEruHBjf3Exph99D/SU/IL1QBaEUhoLvXy8Cbs/w965E3sJdTZ879TEOozpTFvSKTpkMQYmUV7F8r2dhzltyAoEKsvHXADtwnccPaASelzUKzBjpZnGlZYUeMr0y3hkFA9rOVTxqiBB9K5PLfTvYCBi44EgTj74wxuU13ozsqT4WbIJc8fo9H58zXQl2Lro/jRudzIzlXo5YNQYp2+Yy4EfHuBtiwTKlMiaULDmHosqmXfKRd0SFjd+Ack+3qc2uVas+dudmVFi9p+H9vOtYjGqUB3MoVkeilXh/E+eSRJx0PgJB/

Cookie Utilization:

  • The cookie will be utilized for:

    • Textual customizations to site.com (i.e. Welcome, FirstName)

    • Programmatically authenticating visitors between the website, the IBE and the loyalty portal

Security:

For information on how to securely send the encryption key please see the link below

Securely sending private data

Update

To increase security an IV string is prepended to to cookie

IV Parameter

The iv parameter must be 32 characters long, and prepended to the cookie.

  • When setting the cookie it must be prepended to the the encrypted data.

  • When decrypting the first 32 characters of the cookie values should be removed and used as the IV.

PreviousDNS InstructionsNextCross-domain AJAX Authentication

Last updated

Was this helpful?