Token profiles

Sometimes another service needs to know who your user is: an analytics tool, a support widget, a separate API. You don’t want to give it your user’s Pawabase token, which can do too much. A token profile lets a signed-in user request a separate, short-lived token that carries only the facts that service needs, signed so the service can verify it.

Token profiles page — Users & auth → Token profiles: start from a setup.

Your users keep their existing Pawabase sign-in.

In Studio

Users & auth → Developers → Token profiles. Connect another service opens the editor. Choose the identity and access information your service receives. No token syntax required.

The profile

Field	Meaning
Profile name	Your app uses this name when requesting a token, such as `analytics`
Description	What the connection is for
Audience	The identifier your receiving service checks. Usually an API name or URL, such as `https://analytics.example.com`
Token lifetime	Keep tokens short-lived. Your app can request another while signed in
Enabled	Allow signed-in users to request this profile
Require an organization	Only issue tokens for users signed in to an organization they belong to
Require multi-factor authentication	Only issue tokens from a session verified with a second factor (`aal2`)

Claims

A claim is one fact in the token. For each, you set:

Field	Meaning
Claim name	The name your service reads
Value comes from	A field of the user, the organization, an Admin data field, or a Fixed value
Admin data field	A field path such as `user.app_metadata.billing.plan`. User-editable data is excluded, so a person can’t forge a claim
Value type	For fixed values: text, object, true/false, or a list (one item per line)
Require a value	Refuse issuance when this field has no value or fallback
Fallback text	Used only when the source is missing. Arrays and booleans keep their types

Preview

Before you save, use Find a test user and Preview as (with an Organization context) to see the Resolved payload: exactly the claims that person’s token would carry. Use it to prove a claim is right and that private data isn’t leaking.

Use in your app and verify in your service

The editor shows ready-made code for both halves. Verify in your service: tokens are signed with Ed25519 (EdDSA). The receiving service must check the signature, issuer, audience and expiry, using the public verification keys (JWKS) shown on the page.

In your app: request a token

const { token, expires_at } = await pawabase.auth.issueToken("analytics");

await fetch("https://analytics.example.com/ingest", {
  headers: { authorization: `Bearer ${token}` },
});

issued = pb.auth.issue_token("analytics")
issued["token"]

Request a new token when the old one expires; don’t store them long-term. The user must be signed in, and the profile must be enabled.

In your service: verify

Fetch the public keys once (cache them) and verify each token:

import { createRemoteJWKSet, jwtVerify } from "jose";

const keys = createRemoteJWKSet(new URL("https://api.example.com/auth/v1/jwks"));

const { payload } = await jwtVerify(token, keys, {
  issuer: "https://api.example.com",
  audience: "https://analytics.example.com",
});
payload.sub;          // the user id
payload.plan;         // a claim you configured

import jwt   # PyJWT with the cryptography extra

jwks = jwt.PyJWKClient("https://api.example.com/auth/v1/jwks")
signing_key = jwks.get_signing_key_from_jwt(token)
payload = jwt.decode(token, signing_key.key, algorithms=["EdDSA"],
                     audience="https://analytics.example.com", issuer="https://api.example.com")

The same keys are available from the client with pawabase.auth.jwks(). Always check the audience: it stops a token meant for one service being accepted by another.

Design guidance

One profile per consuming service, with the smallest set of claims.
Short lifetimes (minutes), and request on demand.
Put authorisation facts in Admin data fields, never in user-editable metadata.
Require an organization or two-step for profiles that expose sensitive data.

Sessions

The user’s own tokens.

Roles

Facts you can put in claims.

Getting started

Sign-in methods

Sign-up

Security

People

Developers

In Studio

The profile

Claims

Preview

Use in your app and verify in your service

In your app: request a token

In your service: verify

Design guidance

Sessions

Roles

​In Studio

​The profile

​Claims

​Preview

​Use in your app and verify in your service

​In your app: request a token

​In your service: verify

​Design guidance

Sessions

Roles

In Studio

The profile

Claims

Preview

Use in your app and verify in your service

In your app: request a token

In your service: verify

Design guidance