Authorisation

🚧

Important

MediaStore APIs are executed on behalf of the customer (who is authenticated via JWTJWT - JWT (JSON Web Token) - open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. In Cleeng, JWT payload contains: customerId, publisherId, expiration date. JWT is valid for 15 minutes and after that time a refresh token mechanism can be used.), therefore they have only a limited set of features compared to Core Platform APIs. As a benefit, they can be used for building frontend-only integrations without dedicated middleware.

MediaStore SDK uses JWTJWT - JWT (JSON Web Token) - open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. In Cleeng, JWT payload contains: customerId, publisherId, expiration date. JWT is valid for 15 minutes and after that time a refresh token mechanism can be used. for authorisation. JWT payload contains:

  • customerIdcustomerId - Customer identification in Cleeng. This value can be exposed to the public, it will not allow sensitive data access.,
  • publisherIdpublisherId - Publisher identification in Cleeng. This value can be exposed to public, it will not allow sensitive data access.,
  • expiration date.

You can decode JWT using:

  • packages like jwt-decode, or
  • an online decoder like jwt.io

Good to Know

JWT is valid for 15 minutes - the customer should be logged out after 15 minutes.
JWT is required for all methods in the Checkout part (exception: fetch offer details) and for all methods in My Account part. It is returned after successful login and registration.

Refresh Token

The aim of a refresh token is to avoid users' re-login.

A refresh token is issued as part of the authentication process along with the access JWT. The auth server saves this refresh token and associates it to a particular user in the database, so that it can handle the renewing JWT logic.

The renewing JWT logic uses a refresh token to generate a new access JWT in the background (a user is not aware of it) and thus avoids users’ re-login.

Check JWT validity and if it turns out that JWT has expired, call the /auths/refresh_token endpoint.

A refresh token's features:

  • Expiration time - 100 days
  • It can be used only once and expires after that (i.e. if a refresh token has been used to create a new JWT, it should be deleted)
  • A customer can have multiple refresh tokens (for example when he or she accesses an application from multiple devices).

A refresh token is generated in the following endpoints:


Did this page help you?