Access tokens and verifying them

What AuthRobo tokens contain, how to verify them offline against the JWKS, and how refresh works.

Updated July 2, 2026

After a successful sign-in your app holds an access_token and a refresh_token. Here's what they are and how to use them safely.

Access tokens are RS256 JWTs

You can verify them offline against AuthRobo's published JWKS — no network call per request after the keys are cached. Always check:

  • iss equals your issuer (https://authrobo.com)
  • aud equals your client_id
  • exp has not passed
  • sub is the user id
import { jwtVerify, createRemoteJWKSet } from "jose";

const JWKS = createRemoteJWKSet(new URL("https://authrobo.com/api/v1/jwks"));

const { payload } = await jwtVerify(token, JWKS, {
  issuer: "https://authrobo.com",
  audience: process.env.AUTHROBO_CLIENT_ID,
});
// payload.sub = user id

The @authrobo/sdk verify() helper does exactly this.

Refreshing

Access tokens are short-lived. When one expires, exchange the refresh_token for a fresh pair at POST /auth/token. Refresh tokens rotate — always store the new one you get back.

Keep the secret server-side

The exchange and admin endpoints use your client_secret. It must never ship to a browser. The token *verification* above needs only the public JWKS, so it's safe anywhere.

The full user record

To read profile + billing state (plan, subscription_status), call `GET /users/me` with the access token. That's a live read from AuthRobo, distinct from offline JWT verification — use verification for per-request auth, and /users/me when you need the freshest user data.

Ready to build? Create your app → or browse the API reference.