How SigID Works¶
SigID separates global identity from tenant-local application access. Users can reuse one account while tenants retain control over membership, roles, policies, applications, organizations, agents, wallets, billing, and audit logs.
Core objects¶
| Object | Meaning |
|---|---|
| User | A person with a reusable SigID account |
| Tenant | Application or organization boundary using SigID |
| Application | OAuth client configured by a tenant |
| Organization | Shared account or business unit inside a tenant |
| Agent | Software principal that can authenticate and receive tokens |
| Scope | Permission requested by an application, API, or agent |
| Role | Named access bundle assigned by a tenant or organization |
| Policy | Conditional authorization rule |
| Consent | User approval for data sharing or delegated access |
| Delegation | Reduced authority for an agent or service to act for another subject |
| Webhook | Signed event delivery to a tenant receiver |
| Audit log | Tenant-visible record of high-impact events |
Global identity, tenant-local access¶
Users have one SigID account, but each tenant receives a tenant-local view. This protects user privacy and prevents applications from correlating users across tenants without explicit sharing.
Global SigID account
-> tenant A subject: sub_a
-> tenant B subject: sub_b
-> tenant C subject: sub_c
Applications should store the tenant-local subject. Email, phone, social account, and wallet data can change or may not be shared with every tenant.
Hosted auth¶
Applications redirect users to SigID for authentication. SigID handles sign-in, MFA, consent, and token issuance, then redirects back to the application.
Hosted auth provides:
- consistent sign-in methods
- passkey and MFA enforcement
- SSO routing
- consent capture
- tenant branding
- session and recovery flows
- OAuth and OIDC protocol handling
Tenant control plane¶
Tenant administrators use the dashboard and APIs to manage:
- applications
- redirect URIs and origins
- users and invitations
- organizations and SSO
- roles, scopes, and policies
- agents and identity anchors
- managed wallets
- credential vault grants
- webhooks
- billing and usage
- audit logs
Authorization model¶
SigID combines protocol-level scopes with tenant-specific authorization. For the full authorization sequence, see Applications And OAuth.
This lets your application enforce simple scope checks for common API calls while still supporting stricter policy for sensitive actions.
Delegation¶
Delegation lets an agent or service act with reduced authority. SigID narrows access using user consent, tenant policy, requested scopes, subject type, and time limits.
Delegated access should answer four questions:
| Question | Example |
|---|---|
| Who is acting? | Agent, service, or application client |
| For whom? | User, organization, tenant, or agent itself |
| What can it do? | Scopes, tool capabilities, or wallet actions |
| For how long? | Token lifetime, delegation expiry, or task boundary |
Events and auditability¶
Tenant administrators can use audit logs and webhooks to review sensitive actions such as:
- user access changes
- SSO updates
- webhook changes
- agent activity
- key and anchor changes
- vault access
- wallet signing
- policy changes
- billing and commerce events
Audit logs are for investigation and compliance. Webhooks are for integrating SigID changes into your own systems.
Mental model¶
SigID is not only "login." It is a tenant-scoped identity control plane:
| Need | SigID surface |
|---|---|
| Let users sign in | Hosted auth and OAuth |
| Protect APIs | Access tokens, scopes, policies |
| Manage customers | Organizations and SSO |
| Manage people | Tenant users and roles |
| Manage automation | Agents, delegations, vault grants |
| Track changes | Audit logs and webhooks |
| Reduce user correlation | Pairwise tenant-local subjects |