How It Works
- Developer generates a session URL — Your backend calls
POST /v1/principal-sessionswith the user’sprincipalIdand gets back a short-lived session token embedded in a URL. - You share the URL with the user — Via email, in-app notification, settings page link, etc.
- User opens the dashboard — They see all agents with active access, scopes granted, and a revoke button for each.
- User revokes access — One click revokes the grant and cascade-revokes any delegated sub-grants.
Generate a Session URL
Using curl
Using the TypeScript SDK
Parameters
The user’s principal ID — the same
userId / principalId used when creating authorization requests.How long the session token is valid. Format:
"30m", "1h", "24h". Capped at 24 hours.Response
| Field | Type | Description |
|---|---|---|
sessionToken | string | The JWT session token |
dashboardUrl | string | Full URL the user can open in their browser |
expiresAt | string | ISO 8601 expiry timestamp |
What the User Sees
When the user opens the dashboard URL, they see:- Apps with access — A card for each agent with an active grant, showing the agent name, description, granted scopes, issue date, expiry date, and a “Revoke access” button.
- Recent activity — A table of recent audit log entries for actions taken by agents on their behalf.
- Session expired — If the session token has expired, a clear message asking them to request a new link.
Revoking Access
When a user clicks “Revoke access” on a grant:- The grant is marked as revoked
- All delegated sub-grants (child grants from agent-to-agent delegation) are also revoked
- Redis revocation keys are set so tokens are rejected immediately
- A
grant.revokedwebhook event is fired
DELETE /v1/grants/:id endpoint.
Security Considerations
- Short-lived tokens — Session tokens default to 1 hour. Use the shortest duration practical for your use case.
- Scoped access — Session tokens are bound to a specific principal+developer pair. A user cannot see or revoke another user’s grants, and cannot see grants from other developers.
- Purpose claim — Session JWTs include a
purpose: "principal_dashboard"claim that prevents grant tokens from being reused as session tokens (and vice versa). - No API key exposure — End-users never see or need the developer’s API key.
- HTTPS only — Always serve dashboard URLs over HTTPS in production.
API Endpoints
The permission dashboard uses these endpoints under the hood:| Method | Endpoint | Auth | Description |
|---|---|---|---|
POST | /v1/principal-sessions | Developer API key | Create a session token |
GET | /v1/principal/grants | Session token | List active grants |
GET | /v1/principal/audit | Session token | List recent audit entries |
DELETE | /v1/principal/grants/:id | Session token | Revoke a grant |
GET | /permissions | None (public HTML) | Permission dashboard page |