Triunnia Labs

Issue Tokens, Not IDs

The Tokens Api is Arch's dedicated token service. When an application needs to communicate with a user about a sensitive action, it cannot share internal identifiers. The Tokens Api issues short-lived, opaque tokens that stand in for those identifiers across the public boundary and expire when their purpose is served.

The Public Boundary

Internal Identifiers Were Never Meant to Leave the System

A User ID Is Not a Safe Link

When a user requests a password reset, your application sends them a link. That link carries enough information to identify the request when the user returns — but it cannot carry the user's internal ID. Exposing internal identifiers in email links or URL parameters is a known vulnerability class: insecure direct object reference. The Tokens Api closes that exposure by placing an opaque token in the link instead.

Application-Defined Context

Every token carries an owner identifier and a type — both defined by the calling application. The application controls what those values mean and what they authorize. The Tokens Api stores them, returns them on demand, and removes them when they are no longer needed. The interpretation is yours; the lifecycle management is Arch's.

The Server Holds the Mapping

Tokens That the Issuer Controls Completely

Revocable by Design

JWT-style tokens are self-contained — the payload is embedded, and a verifier reads the signature without consulting the issuer. That model makes revocation hard: once a JWT is issued, only expiry ends its validity. The Tokens Api issues opaque tokens whose mapping from token to owner lives on the server. Revoke one and it ceases to exist immediately, regardless of what the holder has already received.

Configurable Lifetime

Each token is issued with a lifetime in minutes, set at creation time. An email verification token might live for twenty-four hours; a password reset token for thirty minutes. The window belongs to the use case, not the platform.

Bound to Its Origin

The IP Address That Created the Token Must Present It

Protection Against Replay

When a token is created, the requesting IP address is stored with it. Validation confirms the token against that IP — a link followed from a different machine fails the check. The binding does not stop an attacker already operating from the same address, but replay from any unrelated origin is refused.

A Platform Primitive

No Equivalent Exists in Cloud Provider Catalogs

Unique to Arch

The major cloud providers offer session managers, short-lived credentials, and signed URLs — but none issue temporary opaque tokens that conceal internal owner identifiers while binding to an IP address. The Tokens Api fills a gap that every identity-aware application eventually faces.

Part of the Identity Stack

The Tokens Api is the binding element in Arch's identity stack. When a user action calls for a confirmation link, the Email Api delivers it — the token inside was issued, validated, and revoked by the Tokens Api.

Connected by Design

Tokens Is the Binding Element in the Arch Identity Stack

Email Api

When a user action requires a confirmation link, the Email Api delivers it — but the token inside was issued, validated, and revoked by the Tokens Api. The two services coordinate without either owning the other's concern. Email handles delivery; Tokens owns the opaque identifier and its lifecycle.

Your Application

Any workflow requiring a temporary, unguessable reference to an internal record uses ITokensApiClient. A single call issues the token; a second validates it and resolves the owner. The token itself reveals nothing — the mapping lives on the server until it is no longer needed.