Authentication tokens are everywhere, but most implementations are basic: just generate a random string and hope it doesn't collide. Discord does better. Their authentication tokens contain encoded information about the user and creation time, making them both secure and auditable.
In this post, we'll explore how to build a similar system that combines the security of encrypted data with the auditability of embedded metadata.
Token Structure
Discord-like authentication tokens are structured into three parts, separated by periods for easy parsing:
Token consists of three base64-encoded parts:
- • User ID – Snowflake identifier, uniquely identifies the user
- • Timestamp – Seconds since epoch, allows token age validation
- • Random String – 25-character secret, ensures cryptographic security
Why This Design?
The user ID is encoded using base64, making it machine-readable but not human-readable. This prevents casual inspection while still being decodable server-side. The timestamp allows you to check token age without database lookups, enabling token rotation and expiration policies.
The random string acts as the actual secret. Even if someone gains access to a token and decodes the user ID and timestamp, they still don't have the random portion. This three-layer approach means each component is individually useful but requires all three for the token to be valid.
Security through obscurity isn't enough, but security through multiple validation layers is solid.
Implementation Benefits
This design integrates beautifully with the Snowflake generator. Your user IDs are already Snowflakes, so you get distributed, time-encoded IDs without extra overhead. You can validate tokens by decoding them and checking timestamps, expiration, and user existence in parallel.
Authentication is critical infrastructure. Building it right from the start pays dividends. Check out the Go-Authentication project to see a production-ready implementation.
View the Go-Authentication Project