Tokens & validation
Access tokens
Section titled “Access tokens”Access tokens are RS256-signed JWTs, audience-bound to the client_id they were issued for, valid for 15 minutes.
They carry these claims:
| Claim | Meaning |
|---|---|
sub | User id |
aud | Your client_id |
iss | The auth platform issuer (your API base URL) |
exp / iat | Expiry / issued-at |
org | Organisation slug |
org_id | Organisation id |
roles | The user’s roles |
app_access | Application ids the user may access |
email / email_verified / name | Profile basics |
Offline validation
Section titled “Offline validation”Consuming APIs validate access tokens locally — the auth API is never called per request. Validation:
- Fetches the public signing keys from
/.well-known/jwks.json(cached, rotation-aware). - Verifies the RS256 signature,
iss,aud, andexp.
Because validation is cryptographic, there’s no per-request revocation check — revocation is handled by the short 15-minute lifetime plus refresh-token rotation, not by the validator. Pin the accepted algorithm to RS256 to block algorithm-confusion attacks (the SDKs do this for you).
The SDKs wrap all of this:
- TypeScript:
verifyAccessToken - .NET:
AddArrowLabsAuth(built on ASP.NET Core’s JWT bearer + JWKS discovery)
Refresh tokens
Section titled “Refresh tokens”Refresh tokens are opaque (not JWTs), stored hashed by the platform, with a 30-day sliding / 90-day absolute lifetime. They rotate on every use — each refresh returns a new refresh token and invalidates the old one. Reusing a rotated token is treated as theft and revokes the session.
The platform session
Section titled “The platform session”The browser portals share an opaque, HttpOnly platform session cookie, scoped per-org, separate from your application’s own session. Your app manages its own session after completing the OAuth flow — the two are independent.