Skip to content

Cookies used by SSO implementation

Auth0 and our implementation rely on cookies to be set. Here is an overview of what cookies you can typically find in the browser of the users and what they are used for.

All cookie values are base64 encoded and can be easily decoded at https://www.base64decode.org.

[[TOC]]

__sso

This cookie holds the main information about the user and the login state of the user. Here is an explanation of the keys found in the JSON structure:

  • id: This holds the ID of the associated user
  • displayName: This value holds the information of what the user's name looks like
  • accessToken: This is the JWT that contains more information. It's a signed value (see below)
  • refreshToken: This field in plays a crucial role in maintaining the continuity of a user's authentication status without requiring them to log in multiple times. See here for an in-depth explanation.

Example value

{
    "id":"auth0|7788761",
    "displayName":"christoph.eicke@statista.com",
    "accessToken":"eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6Ijg5c0ZDdDI2NWdMZEh3UEdodFJ2OCJ9.eyJpc3MiOiJodHRwczovL2xvZ2luLnN0YXRpc3RhLmNvbS8iLCJzdWIiOiJhdXRoMHw3Nzg4NzYxIiwiYXVkIjpbInN0YXRpc3RhLWFwaSIsImh0dHBzOi8vc3RhdGlzdGEuZXUuYXV0aDAuY29tL3VzZXJpbmZvIl0sImlhdCI6MTczNzA5OTgyNSwiZXhwIjoxNzM5NjkxODI1LCJzY29wZSI6Im9wZW5pZCBwcm9maWxlIG9mZmxpbmVfYWNjZXNzIiwiYXpwIjoieGpWRjBGRldGUE9jRzdYSk84QzBYbGVlUlBsbFVGZkkiLCJwZXJtaXNzaW9ucyI6WyJ4bW8iXX0.gqppchHnF0dUx68YUmP6wt6v0PZf1hGA_41luZmoUuQS_5iIqU3U42r-2OrRb6oiqPOswZ4o9erNVCvvnj2YVNACfpma58e55Yk55LPmJ5bdc0CJbAIKH_9dZyihOcWYgCbfbk2XUR4nKGODf0QSYefnE2mVRnuiFWXWN91hSm3kfW4jqIeEVqGwgFN07HGnbCT_mc6ZXn0ycPI3Vhu6iB6mPdQ4p7imjTuy8TF5W7ERe1vIc5hmYMSdmp945Eh2bMHC0Z6gCt2cwV482Q1tvWOMmWrjdEulhn2BFoAbB0xqL8GKoGhq81dXsQM8Tegx74oIRfPicVD2lFCJZsld9Q",
    "refreshToken":"v1.MqcSXOz93OfxjDuiS8PHmzhaWcBYR_55g6oiJaYRJvu-NZoUUxc833NabmWEM6o7N4wWwJ4-631ZX7iHmxzGi3Y"
}

JWT

The accessToken key holds the JWT for the logged in client. The JWT can be decoded at https://jwt.io

Here is an explanation of the JSON structure:

  • iss (issuer): Identifies the principal that issued the JWT. Here, it's "https://login.statista.com/", indicating that the token was issued by Statista's login server.
  • sub (subject): Identifies the principal that is the subject of the JWT. The value "auth0|7788761" indicates an identifier unique to the user in the context of an Auth0 authentication system.
  • aud (audience): Identifies the recipients that the JWT is intended for. It includes "statista-api" and "https://statista.eu.auth0.com/userinfo", suggesting that the token is valid for use with the Statista API and also for accessing user information through Auth0’s endpoint.
  • iat (issued at): Indicates when the token was issued, represented as a Unix timestamp (number of seconds since January 1, 1970, UTC).
  • exp (expiration time): Indicates the time after which the JWT must not be accepted for processing. It's also a Unix timestamp. The value defines the exact moment when this token will expire.
  • scope: Defines the permissions or access levels that are associated with this token. In the example case (see below), "openid profile offline_access" suggests that the token grants scopes for OpenID Connect authentication, access to the user's profile, and offline access capabilities, enhancing functionality when the user is not actively online.
  • azp (authorization party): This is usually the OAuth 2.0 Client ID of the party that requested the token. It indicates the application that made the authentication request.
  • permissions: Lists specific permissions or roles granted to the token bearer. Here, the token includes permission "xmo" which would typically be a custom-defined permission within the Statista application environment, granting specific access or capabilities based on implementations.

Example value

{
  "iss": "https://login.statista.com/",
  "sub": "auth0|7788761",
  "aud": [
    "statista-api",
    "https://statista.eu.auth0.com/userinfo"
  ],
  "iat": 1737099825,
  "exp": 1739691825,
  "scope": "openid profile offline_access",
  "azp": "xjVF0FFWFPOcG7XJO8C0XleeRPllUFfI",
  "permissions": [
    "xmo"
  ]
}

__sso_iplogin

This cookie keeps the state about the IP-login. Here is an explanations of the keys found in the JSON structure:

  • wasIPLoginAttempted: this indicates if we already tried to login this client through their IP
  • isLoggedInWithIP: this indicates whether the client has been successfully logged in by their IP
  • version: we can increment the version in case we want to invalidate all current IP logins
  • ipUsedForLogin: this value holds the IP address of the client, anonymized to a certain degree. It is used to check on the monolith whether this request comes from the same IP that we previously saw when we set this cookie.

Example value

{
    "wasIpLoginAttempted":true,
    "isLoggedInWithIp":true,
    "version":1,
    "ipUsedForLogin":"93.196.0.0"
}

__sso_cookie_checker

Example value

This cookie holds the IP address of the client doing the request. This is part of the "Fernando solution" where we set a cookie just to check if the client using our site is accepting cookies at all. It is set wit the initial request to the monolith and then checked on the remix-sso app after a redirect to it, to see if it exists. If it exists, the client is accepting cookies and we will attempt an IP login. If the cookie does not exist we will stop because Auth0 does not work without cookies.

This has been introduced to stop bot traffic causing errors in our logs that do not accept cookies.

93.196.7.109

__sso_status

This cookie is present if the client is logged in. It then simply holds the value true. If it's not present, the client is not logged in.

Example value

true
Last updated: March 24, 2026 at 10:39
By: Axel Tetzlaff