Trongate Docs
switch to dark modeswitch to dark mode
How Trongate's Token System Works

How Trongate's Token System Works

The Trongate framework has an inbuilt token system to help with the business of authorization and authentication.  At the moment, this system is database driven.  This means you'll be required to have your app connected to a MySQL database to take advantage of Trongate's token system.

An Overview Of How It Works

Trongate's token system is based around three modules working together - each of which has a corresponding database table of the same name. The three modules/database tables required for token authorization and authentication are:

  • trongate_user_levels
  • trongate_users
  • trongate_tokens
  • The image below shows how these three tables are related.

    viewing Trongate's three 'security tables' via Trongate's Graphical Query Builder

    Guiding Principles

    To use Trongate's token system, the following guiding principles should be adhered to:

    • All user levels that your app requires should be represented with a row on the 'trongate_user_levels' database table.  An example of a user level is 'admin'.
    • All users (i.e., website visitors) who are going to be using Trongate's token system for authentication and/or authorization should have a corresponding row on the 'trongate_users' database table.
    • When a user successfully logs in (for example, by submitting a correct username and password), a token should be generated and stored in the 'trongate_tokens' table.
    • The user may then have the token automatically stored on their device.
    • If the user attempts to access a private API endpoint (or webpage), the user can either submit a token (as part of an HTTP request header) or they can have Trongate attempt to fetch a valid token from the user's device.
    • If a token has been found or submitted, Trongate will then attempt to authenticate the user by evaluating the token.
    • Trongate may then grant or refuse access, based upon whether or not the token was valid.
    • All generated tokens have an expiration date.  On the server side, the Trongate framework automatically deletes expired tokens from the trongate_tokens database table. 

    Token Integration From A Database Perspective

    Let's imagine that you're building a private members' website.  This website may feature a 'members' database table.  Members of the website may log in by submitting a username and password on some kind of login form.  The 'members' table may contain a wide variety of fields such as 'first_name', 'last_name' and 'email'.

    In order to give our members full usage of Trongate's token system, we can:

    • add a new row onto the 'trongate_user_levels' table with a title of 'member'
    • give every member an entry on the 'trongate_users' table
    • add a 'trongate_user_id' row onto the 'members' table with a value that matches the 'id', on the trongate_users table, for this user.

    With these three steps, members can now be connected to Trongate's token based security system.

    linking a 'members' table to Trongate's token system

    Stepping Into The Future

    The mechanism outlined above is extremely flexible and future proof.  That's because: 

    Trongate doesn't have to get involved with the mechanics of logging people in for security tokens to work!

    In the hypothetical situation above, we visualised a traditional username and password based method for logging users in.  What's remarkable is the fact that Trongate doesn't have to know about how users are logged in.  All Trongate has to do is distribute and manage security tokens.  This feature makes the Trongate framework an attractive choice for mobile app developers and JavaScript developers who have a need for generating secure, custom API endpoints quickly.

    A Distributor And Manager Of Tokens

    Whenever a significant event happens on our app that ought to be assigned to a user, Trongate's job is to simply generate a token and then wait.

    Token generating events can include:

    • a user has successfully clicked on a 'confirmation' link
    • a payment has been received
    • a user has subscribed to a service
    • a user has just landed on a 'welcome' page
    • a new account has been created
    • a set of questions have been successfully answered

    The precise nature of the events that result in tokens being generated is a matter for you, the developer, to decide!  Furthermore, the mechanism by which users store tokens on their device doesn't matter, from the perspective of the Trongate framework.  Trongate's job is to simply generates tokens, validate them and then automatically delete them from the database, once they've expired.

    Did You Know?
    There are already some developers using Trongate's token system to build APIs for Flutter applications!

    Let's take a closer look at the three database tables that make Trongate's token system work...



    If you have a question or a comment relating to anything you've see here, please goto the Help Bar.