Session Identity Verification Automation: Reading a Token Is Not the Same as Verifying It

A JSON Web Token is built from three parts joined by dots, and the middle part — the payload, carrying claims like a user's own identifier — is simply base64-encoded, not encrypted and not scrambled in any way that resists reading. Decoding that middle part and reading its contents is a completely ordinary, harmless operation that reveals exactly what the token CLAIMS. It reveals nothing at all about whether those claims are true, because the only mechanism that actually ties a token to a real, authenticated event is its separate, third part: a cryptographic signature, produced by the issuing authority's own private key, verifiable only by checking it against that authority's known public key or by asking the authority directly. Code that reads a token's claims without ever checking its signature is reading a claim, not confirming a fact — the two operations look almost identical in code, and only one of them is actually security.

Both operations start from the identical raw material — a session cookie holding a token-shaped string — and both produce the identical-looking output: a user identifier a function can act on. The difference lives entirely in ONE additional step that a decode-only implementation can skip without producing any visible error: actually checking the token's cryptographic signature, which requires either verifying it locally against the correct public key or asking the issuing authority directly. Skipping that step does not break anything for a genuine, legitimately-issued token — decoding its payload directly happens to produce the same correct-looking user identifier a proper verification would have. The gap becomes exploitable only for a token that was never legitimately issued at all, which a decode-only check has no way to distinguish from a real one.

Centriu Loop's own function for resolving the current user from a session cookie previously extracted the underlying access token from the cookie's own value, then base64-decoded the token's payload segment directly and read a `sub` (subject) claim from the decoded JSON as the authenticated user's identifier — returning that value straight to every caller across the application as the confirmed, current user. Decoding a token's payload is a purely mechanical operation on data the token itself carries; it does not, on its own, confirm that the token was genuinely issued by Supabase's own authentication service, that it has not been tampered with, or that it has not already expired. Nothing in the prior code performed that confirmation at all — any string shaped like three base64 segments joined by dots, wrapped in the format the cookie parser expected, and carrying a `sub` claim of the caller's choosing, would have been decoded and trusted identically to a real, properly-issued session.

The fix introduces a dedicated verification function that sends the extracted token to Supabase's own authentication endpoint (`auth.getUser`), which independently validates the token's cryptographic signature, confirms it has not expired, and confirms it was issued for the correct audience — returning a genuinely verified user id only when all of that holds, and returning nothing at all otherwise. Because that verification is a real network call to an external service, and because Centriu Loop needs to resolve the current user on effectively every request, the fix adds a short-lived cache: a verified result is kept for up to sixty seconds, explicitly capped so it can never outlive the token's own real, cryptographically-declared expiration time, and the cache itself is bounded in total size with older entries pruned once a ceiling is reached — keeping the correctness gain from real verification while keeping its performance cost genuinely small. Every function elsewhere in Centriu Loop that previously called the decode-only version was switched to the new, verified version, so the fix closes the gap for every caller across the module at the single point where user identity is actually resolved, rather than needing to be applied separately at each call site.

Before the fix, presenting a name badge at the door was enough to be let in — the door staff read the name printed on it and waved the bearer through, with no one ever checking that name against the actual guest list. Anyone could print their own badge with any name on it. After the fix, the exact same badge is checked against the real guest list before anyone is admitted — the badge alone no longer grants entry; only a badge the list itself confirms does.

Centriu Loop's server-side session check now cryptographically verifies every session token against Supabase's own authentication service before trusting any identity it claims — closing a gap where a token's own, unverified payload had previously been read and trusted directly, with no signature check anywhere in that path.

This automation covers specifically how Centriu Loop's own internal dashboard resolves and verifies a signed-in user's session. It is a distinct mechanism from this pillar's separate pages on Loop's public, unauthenticated consumer credential portal — that portal uses its own dedicated, revocable 192-bit credential system entirely, not a Supabase session token of the kind this page addresses.

Decoding a token's payload locally is fast, requires no network call, and is the simplest possible way to read what a token claims — which is exactly why it is tempting to treat that claim as sufficient on its own. It provides zero actual security guarantee, because reading a claim and confirming a claim's authenticity are different operations entirely. Verifying a token against its actual issuing authority is the only version of the two that confirms genuineness — at the cost of a real network call, which a short, tightly-bounded cache can absorb without meaningfully reducing the strength of the guarantee.