The auth server at https://auth.sigmaidentity.com is built so a person, an application, or an AI agent can find and use every protocol on it without a human in the loop. This page lists those surfaces in one place. The server's home page links to them in its footer; the explanation lives here.
Two domains, two jobs
sigmaidentity.com is documentation and product pages. auth.sigmaidentity.com issues tokens and serves the discovery documents below. See About Sigma Auth for the split.
Discovery documents
| Surface | URL | What it is for |
|---|---|---|
| Developer and agent portal | /developers | Quickstart, Dynamic Client Registration sandbox on the live host, and the versioning policy |
| API catalog (RFC 9727) | /.well-known/api-catalog | A linkset of every machine-readable surface on the server |
| OAuth 2.0 server metadata (RFC 8414) | /.well-known/oauth-authorization-server | Endpoints, grant types, PKCE methods, and scopes supported |
| OpenID Connect discovery | /.well-known/openid-configuration | OIDC issuer, JWKS, and userinfo configuration |
| Agent Auth discovery | /.well-known/agent-configuration | Capabilities AI agents can request, with the approval method for each |
| OpenAPI specification | /openapi.json | Better Auth API schema (under /api/auth) with operationIds and named scopes |
| Interactive API reference | /api/auth/reference | Browsable version of the OpenAPI document |
llms.txt | /llms.txt | Plain-text orientation guide for AI agents |
| MCP (Streamable HTTP) | POST /.well-known/mcp | Server-side Model Context Protocol endpoint. GET returns 405 by design. |
The OpenAPI document is the source of truth for the auth endpoints it contains. The BRC-100 certificate wallet endpoints are documented separately in the Wallet Credentials reference.
Protocols on the server
- OAuth 2.1 authorization code with PKCE for browser and native applications.
- OpenID Connect ID tokens and userinfo on top of the OAuth flow.
- Device Authorization Grant (RFC 8628) for headless agents and devices without a browser. People approve at
/device. - Dynamic Client Registration (RFC 7591) so an agent can register a client programmatically before its first sign-in.
- Agent Auth capabilities: short-lived, scoped tokens an agent requests for a specific action, with the approval method declared in the agent configuration document.
How each audience uses it
People
A person generates a Bitcoin identity (a BAP key) in the browser at /signup, unlocks it at /login with a password, a passkey (PRF), or a social restore, and approves device flows at /device. The private key never leaves the device. The server only verifies signatures.
Applications
Applications integrate through the standard authorization code flow with PKCE. Better Auth projects can install the plugin instead of wiring the flow by hand:
bun add @sigma-auth/better-auth-pluginimport { betterAuth } from "better-auth";
import { sigmaProvider } from "@sigma-auth/better-auth-plugin/provider";
export const auth = betterAuth({
plugins: [
sigmaProvider({
sigmaAuthUrl: "https://auth.sigmaidentity.com",
}),
],
});import { createAuthClient } from "better-auth/client";
import { sigmaClient } from "@sigma-auth/better-auth-plugin/client";
export const authClient = createAuthClient({
plugins: [sigmaClient()],
});The full walkthrough, including the callback handler and the Next.js catch-all route, is in Setup.
Agents
An agent can register an OAuth client programmatically, authenticate headlessly with an agent-held BAP identity key using Bitcoin-signed requests, and request scoped capabilities through Agent Auth. Create the key at /signup or locally with bsv-bap; the server never holds private keys. Start with /llms.txt and the developer and agent portal.
Built on
The server runs on Better Auth and uses bitcoin-auth for signature verification. See Bitcoin Authentication for how the signatures work.