Migrating to Authorization Header

To be compliant with the Chrome's upcoming limitations regarding the use of third-party cookies, as of May 31, 2024, the JWT token will be also returned into the body of the login API response, and it must be sent back inside the Authorization header as a bearer token.

Note that the old cookie-based mechanism will continue to operate until the end of 2024.

Here is the new login response body:

{
  "token": "eyJhbGciOiJIUzUxMiJ9.eyJsYXN0TG9naW5Ua********",
  "refreshToken": "2f2c67a7-8c41-479b-b6ff-*****",
  "userId": "964ca322a6129f463ad55ee3",
  "tenantId": "961539a889504796e231d68b"
}

Into the new response body, you can find the token that must be stored locally by the client, and the refreshToken that you can use, along the userId and tenantId, to obtain a new JWT token.

Each authenticated request must include the Authorization header as below:

Authorization: Bearer eyJhbGciOiJIUzUxMiJ9.eyJsYXN0TG9naW5Ua******** 

In the API key declaration, you can specify whether the client should exchange the JWT token via cookies; by default, this option is disabled for new API keys, so it is suggested to start using the Authorization header instead.