Authentication & authorization
Last updated
Last updated
More authentication information can be found on the Google Identity Toolkit API website.
The fulfillmenttools platform is secured using an external Identity Provider (Google Identity Toolkit) that issues JWT tokens in exchange for a valid username and password. This JWT token securely encodes (among other things) your username, your role, and which facility you are assigned to. Authorization against our API works by using an issued JWT Token in every request as an HTTP header.
All requests to the fulfillmenttools platform requiring authentication should contain the following auth header:
To retrieve an authentication token for a given user, send an HTTP POST call to this API endpoint:
authKey
, email
and password
have to be valid to your fulfillmenttools instance and are being given to you when the instance was created.
There is an imposed rate limit on calls towards the Google Identity Toolkit for new tokens based on username & password (see Google Identity Platform - Quotas). This could be especially relevant for connector implementations as it might be feasible to cache & share tokens between function invocations.
As a result, an answer looks similar to this response:
Two attributes in the above response are of special importance:
idToken
is the actual JWT you need to send along every REST Call you issue against the fulfillmenttools API. It has an expiration period depicted by the attribute expiresIn
. In this case, it is valid for 3600 seconds. After that, you need to get a fresh token.
refreshToken
should be used to get a fresh token without providing the credentials again.
Every call to the fulfillmenttools API must include the JWT in an Authorization-Bearer header.
To refresh a token, send an HTTP POST call to this API endpoint:
fulfillmenttools have a simple roles and permissions system that cannot be edited currently. Depending on the role, the corresponding user has access to data (or not) for which he has the necessary authorization. The prerequisite is, of course, a valid authentication.
A user must always have exactly one assigned role, reflected in the JWT. That means a role switch is available after a token refresh.
There is a fixed set of roles a user can take within the platform:
FULFILLER
yes
Takes care of the operative workflow, such as picking or packing. Users have primarily access to operatively needed parts of the system.
SUPERVISOR
yes
Supervisor role extends the role of the Fulfiller. It is allowed to configure the settings of certain facilities.
ADMINISTRATOR
no
The Administrator of a fulfillmenttools system is allowed to access all the functionality.