Understanding Trongate's Token System

Trongate comes with its own battle-tested token system for authorization and authentication.

Authentication answers "Who are you?" Authorization answers "What can you do?" Trongate handles both with tokens.

A token is a random string stored in your database. When a user logs in successfully, you generate a token. That token proves their identity on every subsequent request.

With Trongate's token system, there are no sessions to manage. No JWT overhead. No auth middleware chains. Just three database tables and some Native PHP.

The Three Security Tables

Trongate's token system uses three relational database tables. Each has a specific job:

• trongate_user_levels - Defines roles (admin, member, guest, etc.)
• trongate_users - Links users to roles
• trongate_tokens - Stores active tokens with expiry dates

Table 1: trongate_user_levels

This table defines every role in your application.

SQL Statement:

Sample data:

That's it. One row per role. The id is what you'll reference when checking permissions.

Table 2: trongate_users

This table represents every user who needs a token.

SQL Statement:

Sample data:

Key Points

• id - Auto-incrementing primary key. This is the "Trongate User ID" referenced throughout the system.
• code - Random 32-character string for privacy. Use this in URLs instead of exposing numeric IDs.
• user_level_id - Links to trongate_user_levels.id via foreign key.

Table 3: trongate_tokens

This table stores active authentication tokens.

SQL Statement:

Key Points

• id - Auto-incrementing primary key.
• token - The randomly generated token string (typically 32 characters).
• user_id - Links to trongate_users.id via foreign key.
• expiry_date - Unix timestamp. Tokens expire automatically.
• code - Internal use by the API manager (max 3 characters). Usually left as '0'.

When a user logs in, you insert a row here. When they log out, you delete it. Expired tokens are purged automatically.

How The Tables Connect

Here's the relationship:

This means:

• Every token belongs to a user
• Every user has a level
• Query any token to instantly know the user's role

Connecting Your Application Tables

Let's say you have a members table with columns like first_name, last_name, email, and password (hashed, obviously).

To integrate with the token system:

1. Add a trongate_user_id column to your members table
2. When someone registers, create a record in both members AND trongate_users
3. Store the trongate_users.id in members.trongate_user_id

Example schema:

Now when a member logs in:

1. Validate their email/password against the members table
2. Grab their trongate_user_id
3. Generate a token for that trongate_user_id
4. Store the token in trongate_tokens

Why This Design Works

Three tables. Clear responsibilities. No magic.

• Scalable: Add as many user types as needed without touching the token system
• Secure: Passwords live in your app tables, not framework tables
• Simple: One foreign key lookup tells you everything about a token
• Fast: Indexed queries, no complex joins required for validation

In the next section, we'll walk through exactly how tokens flow through this system from login to logout.