Customer Login by Token: reference information

Edit on GitHub

A token is a unique identifier that contains all the information needed for authentication to fetch a specific resource without using a username and password. The tokens are JSON strings that are encoded in base64url format.

The lifetime of the token is 8 hours by default, but this value can be changed at the project level.

Token structure

Every token consists of three sections separated by periods.

Token structure

  • The header contains the information about the token type (JWT) and the encryption algorithm (RS256). For example:
  "typ": "JWT",
  "alg": "RS256",
  "jti": "9ced66ac5cefe17681576bf95b800078e3020142faaa524da871ffb2a63508952045e10453136bde"

Once the header is encoded, we get the part of the token:

  • The payload stores multiple claims (statements) about the user’s identity and additional data—for example, permissions. Here, you can find the needed information for transmission. The id_customer and idcompanyuser identifiers are included by default. However, you can extend the payload with any data according to your project requirements.

Example payload:

     "aud": "frontend",
      "jti": "9ced66ac5cefe17681576bf95b800078e3020142faaa524da871ffb2a63508952045e10453136bde",
      "iat": 1557926620,
      "nbf": 1557926620,
      "exp": 1557955420,
      "sub": "    {/"customer_reference/":null,/"id_customer/":6,/"id_company_user/":/"1/",/"permissions/":null}",
  "scopes": []

The example above contains six registered claims that, when encoded, correspond to the following:

  • The signature contains the hash of the header, payload, and secret needed.

The following is an example signature:

  base64UrlEncode(header) + "." +

The final part of the encoded token looks like this:


Combining the three parts, an example URL with the full token looks like the following:

In the Spryker Commerce OS, token generation is performed using a facade method, which is why no GUI is present. To generate a token, see HowTo: Generate a token for login.

To make the feature more flexible, we have implemented the functionality that lets you disable switching between the Business-on Behalf accounts. For example, if the user logs in to the pre-defined company account that has Business-on-Behalf feature integrated, the shop owner can disable the ability to switch between the accounts. In case the Business-on-Behalf is disabled, the company user logs in to the default account and can’t switch between the company users within their company account.