Claims And Scopes¶

Ask about this page: Claude ChatGPT Grok

Use this page to understand token fields and authorization strings. For the developer validation path, start with Verify Tokens.

Common Token Claims¶

Ask:

Claim	Meaning
`iss`	Issuer. Must match the expected SigID issuer.
`sub`	Subject identifier. Use with tenant context as the app user key.
`aud`	Audience. Must match the protected API.
`exp`	Expiration time. Reject expired tokens.
`iat`	Issued-at time. Useful for debugging and freshness.
`jti`	Token identifier. Useful for replay, audit, and revocation workflows.
`scope`	Granted scopes. Check before serving protected routes.
`tenant_id` or tenant context	Tenant/workspace context for isolation checks.
`org` or organization context	Active organization when relevant.
`amr`	Authentication methods used.
`acr`	Authentication assurance or context class.
`cnf`	Confirmation claim for sender-constrained tokens such as DPoP.
`act`	Actor claim for delegated access or token exchange.

Claim names and exact availability depend on token type, flow, client, deployment, and configured policies.

Tenant binding is opt-in in the SDK

The token always carries tenant_id, but the SDK's tenantId validation option is optional – when it is omitted, no tenant binding is performed and a token from any tenant is accepted. Single-tenant resource servers must always pass tenantId; multi-tenant ones must scope every data lookup by the validated claims.tenantId. See Verify Tokens.

Subject Types¶

Ask:

SigID can represent multiple principal types:

Subject type	Typical use
`human`	Person using an account.
`agent`	Software principal or AI agent.
`system`	Service or automation principal.
`anonymous`	Guest or trial subject where enabled.

APIs should reject subject types that are not expected for the route.

Scope Design¶

Ask:

Scopes should describe API permissions, not UI labels. Use narrow scopes that map to backend actions, such as:

Scope pattern	Example
Read	`projects:read`
Write	`projects:write`
Admin	`admin:write`
Billing	`billing:read`
Agent tool	`tools:calendar.read`

Keep scope names stable, reviewable, and least-privilege.

Delegation Claims¶

Ask:

In SigID-issued delegated tokens, sub identifies the acting agent and subject_type is agent. The act chain records the grantor context and delegation IDs. A single-level example is:

{
  "sub": "pairwise-agent-subject",
  "subject_type": "agent",
  "tenant_id": "tenant-uuid",
  "aud": "https://api.example.com",
  "scope": "projects:read",
  "act": {
    "sub": "pairwise-grantor-subject",
    "delegation_id": "delegation-uuid"
  }
}

This is an illustrative claims excerpt, not a usable token. Nested act claims represent additional grantor links. Use the validated agent subject for caller audit and apply the grantor/resource policy when serving human-owned data. Pairwise subjects are scoped to the audience; do not treat them as global user IDs or replace them with an email address.

In the JavaScript validator, allowDelegation: true allows the act claim and returns it as claims.actor. That option alone does not verify the actor chain, require a delegation, establish current revocation state, or prove fresh human approval. Enforce the policy your tool or resource requires before executing it.

For agent-specific flows, read Agent And MCP Auth.