Skip to main content
The SDK’s GatelitClient calls getToken() before every request. What that function returns determines how the gateway identifies and authorizes the request. Three schemes are available — pick the right one for your deployment.

Service keys (GatelitKey)

Long-lived keys for backend use. Create them in the dashboard under Settings → Service Keys.
Pros: Simple. No token lifecycle management. Cons: Long-lived. Revocation requires deleting the key. When: Server-side scripts, CI, cron jobs, or any backend where managing short-lived tokens is overhead.
Never use GatelitKey in browser code. It’s a long-lived secret — anyone who extracts it can make requests indefinitely.

Signed tokens (GatelitSigned)

Your backend issues short-lived HMAC-signed JWTs. The gateway verifies them without a database call. Backend — Nuxt server route example:
Frontend — fetch the token before each request:
Pros: Short-lived (60s default). Encodes per-user constraints. No DB hit for verification. Cons: Requires a backend endpoint to issue tokens. When: Frontend apps with authenticated users. This is the recommended pattern for production browser apps.
GATELIT_SIGNING_SECRET must match between your backend and the gateway. Both sign and verify with the same secret.

OIDC tokens (Bearer)

OIDC authentication is in Alpha. Full self-serve configuration is coming soon. Contact us if you need OIDC support today.
Pass the user’s existing OIDC JWT directly:

Caching tokens

getToken is called before every request. Add caching to avoid unnecessary work:
For signed tokens with a 60-second TTL, refresh the cache slightly before expiry.