The ClearBlade Platform allows for Systems to define and customize their own user registry.

The users that get created have special permissions, allowing them to only view and edit properties related to them.

Users are given authentication tokens that will work for a session and expire after a certain time

ClearBlade Overview

Creating Users

Creating users can be done via HTTP endpoint or via the GUI. It requires an email for the user and a password. Other information that the developer may require can be processed via that endpoint. Once a user is created, it has no default permissions to any resource on the platform. Roles must be associated with users. The developer must supply their first and last name, their organization, and an email and password to register.

Managing users

User management may be performed via the API or the GUI. It’s possible to add and remove roles from users, alter the permissions of roles, and many other things. Note that if you alter or delete a role, that change will propagate to every user who has that role. It’s also possible to delete users from the platform. This will immediately stop their session and log them out.



The ClearBlade platform’s security design is based off of the idea of Role Based Access Control (RBAC).


To allow groups of users to see specific applications and perform certain actions with permissions. All resources can have permissions for create, read, update, and delete.


Permissions can be applied to roles, rather than directly to the user. The users are associated with those roles.

Creating Roles

This may be done via the GUI or via an endpoint. Roles are created and permissions are assigned to them. Those permissions correspond to operations on various resources. Note that users may have multiple roles. So, if a user has a role that has certain permissions and has another role that doesn’t, the user will have the permissions, even though one of their roles doesn’t specify them.


  • The user sends a request to the Authentication endpoint containing:

    • username
    • password
    • System Key
    • System Secret
  • If the login information is valid, the user is returned a token. The token is valid for a configurable number of days (the default is 30 days).

  • That token is attached as a header to each subsequent API request. The token is required for all transactions within the platform (except logging in).

  • When a user logs into the platform, they are issued a token that they must use for every platform request.

  • Each token is associated with a session, which is a record of who is logged in at any given moment. The session does not correspond to the permissions applied to a role, so if the permissions are changed on a role, the changes will apply even to users who are currently in a session.