Skip to content
Authometry
  • Product
  • Integrate
  • Security
  • Docs
GitHub(opens in a new tab)Sign inGet started
  • Product
  • Integrate
  • Security
  • Docs
  • GitHub (opens in a new tab)
  • Sign in to the console
  • Get started

platform.reference

How Authometry works, in detail.

The protocol flow, standards coverage, configuration workflow, agent delegation, events, and security controls behind every trace — for when you want to verify the claims on the front page.

  1. Protocol flowAuthorization Code with PKCE, hop by hop
  2. StandardsEvery supported grant, endpoint, and RFC
  3. ConfigurationYAML manifests, plan, and apply
  4. Agents and MCPDelegated, bounded agent identities
  5. EventsSigned webhooks, API, and MCP access
  6. SecurityThe controls, stated precisely
  7. Self-hostingRuntime topology and deployment
  8. Error explanationsWhat the client sees vs. what is recorded

protocol.flow

Follow authentication from request to token.

Authorization Code with PKCE, as it actually crosses the wire — and what Authometry checks at each hop before anything is issued.

Interactive example · demo data

02 / 08

Authorize

The browser is sent to the authorization endpoint with a PKCE challenge.

Browser → Authometry

GET /oauth/authorize

response_type
code
client_id
itsagram-web
redirect_uri
https://itsagram.com/auth/callback
scope
openid profile media:read
state
01K8F7Q4GZ3M9V2XWQH6
nonce
n-0S6_WzA2Mj
code_challenge
E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
code_challenge_method
S256

Authometry checks

  • The client exists and is active.
  • The redirect URI exactly matches a registered value.
  • Every requested scope is assigned to the client.
  • An S256 challenge is present.

Recorded in the trace as

  • Request received
  • Client verified
  • Redirect URI matched
  • PKCE challenge validated

standards

Built on the standards.

OAuth 2.0 and OpenID Connect, implemented plainly. Any compliant client library works; there is no proprietary protocol to adopt or migrate away from.

Deliberately not supported

  • Implicit
  • Hybrid
  • Resource owner password
  • plain PKCE
  • JAR
  • JARM
  • CIBA

Authometry ships conformance-oriented tests. It is not OpenID Certified; certification requires a separate submission to the OpenID Foundation.

Protocol documentation

OAuth 2.0 grants

  • Authorization CodeRFC 6749 §4.1/oauth/authorizeThe only advertised response type
  • PKCERFC 7636S256 only; plain is rejected
  • Refresh TokenRFC 6749 §6/oauth/tokenRotates on every use; reuse revokes the family
  • Client CredentialsRFC 6749 §4.4/oauth/tokenMachine applications act as themselves
  • Device AuthorizationRFC 8628/oauth/device/authorization600 s codes, 5 s polling interval
  • Token ExchangeRFC 8693/oauth/tokenOne-level agent delegation with reduced scope

OpenID Connect

  • DiscoveryOIDC Discovery 1.0/.well-known/openid-configurationEndpoints derive from the environment issuer
  • JWKSRFC 7517/.well-known/jwks.jsonActive and retiring RS256 keys by kid
  • ID TokenOIDC Core 1.0RS256, nonce echoed when sent
  • UserInfoOIDC Core §5.3/oauth/userinfoClaims gated by the granted scopes
  • RP-Initiated LogoutOIDC RP-Initiated Logout/oauth/logoutRedirects only to a registered URI

Token lifecycle

  • RevocationRFC 7009/oauth/revokeNon-enumerating; refresh revokes the family
  • IntrospectionRFC 7662/oauth/introspectOnly for the authenticated client’s tokens
  • private_key_jwtRFC 7523Alongside client_secret_basic, _post, and none

Agents and MCP

  • Pushed Authorization RequestsRFC 9126/oauth/parSigned requests from registered agents
  • DPoPRFC 9449Agent tokens bound to a key with cnf.jkt
  • Resource IndicatorsRFC 8707Tokens scoped to the target resource
  • Protected Resource MetadataRFC 9728/mcpPublished by Authometry’s MCP server
  • Dynamic Client RegistrationRFC 7591Public MCP clients only

configuration

Auth configuration belongs in your workflow.

Define applications, scopes, claims, and policies as YAML next to your code. Each environment is a target; every change is a pull request.

  1. Reviewgit diff
  2. Validateauthometry validate
  3. Planauthometry plan
  4. Deployauthometry apply

Interactive example · demo data

Restrict Itsagram media to workspace members #184

jiayang wants to merge media-access into main

validate plan+31 −1

1+apiVersion: authometry.dev/v1alpha1
2+kind: Policy
3+metadata:
4+  name: workspace-member
5+spec:
6+  displayName: Workspace member
7+  description: Only Bellaire Media members can use Itsagram.
8+  enabled: true
9+  applications: [itsagram-web]
10+  match:
11+    all:
12+      - field: user.groups
13+        operator: contains
14+        value: bellaire-media
15+  decision:
16+    allow: true
17+  otherwise:
18+    deny:
19+      code: access_denied
20+      message: A Bellaire Media workspace account is required.

What Authometry applies to production

PolicyWorkspace member Enabled
Applies toitsagram-web
All must matchuser.groupscontainsbellaire-media
ThenAllow
OtherwiseDenyaccess_deniedA Bellaire Media workspace account is required.

Managed by manifest policies/workspace-member.yaml

CI
$ authometry validate --directory authometry
✓ 1 Application resources valid
✓ 1 AuthometryInstance resources valid
✓ 1 Policy resources valid
✓ 1 Scope resources valid

Configuration is valid.

$ authometry plan --directory authometry
  ~ Application/itsagram-web
  = AuthometryInstance/primary
  + Policy/workspace-member
  + Scope/media-read

Plan: 2 create, 1 update, 0 delete, 1 unchanged.

agents

Identity isn’t just human anymore.

Agents, services, CLIs, and MCP clients act on someone’s behalf. Authometry gives each a registered identity, bounds what a task may do, and records who acted for whom.

Interactive example · demo data

  • PeopleSessions, policies, and consentAuthorization Code + PKCE
  • ServicesThe application is the subjectClient Credentials
  • Devices and CLIsA user code approved elsewhereDevice Authorization
  • MCP clientsAdmin-approved mcp:read and mcp:writeCode + PKCE + resource
  • AgentsDelegated, task-bound, sender-constrainedSigned PAR + DPoP

Scoped, audited authorization

Disabling an agent disables its OAuth client and revokes every active grant.

caption-assistantoperated by bellaire-media

Registered capabilities
media:readmedia:write
Resource
https://api.itsagram.com
Task
Add alt text to 42 photos in the Autumn issue
Requested
media:readmedia:write

POST /oauth/par Authorization: AgentAssertion eyJhbGciOi…

  1. Agent identifiedcaption-assistant
  2. Agent signature verifiedSingle-use assertion accepted
  3. Task authority boundedFits the agent registration
  4. User authenticatedmaya@bellaire.media
  5. Delegation grant createdApproved by Maya, 15 min lifetime

Access token, bound to the agent’s key

{
  "sub": "5b0f6c1e…",
  "act": { "sub": "caption-assistant", "operator": "bellaire-media" },
  "aud": "https://api.itsagram.com",
  "scope": "media:read media:write",
  "authometry_grant_id": "0f9b…",
  "cnf": { "jkt": "NzbLsXh8uDCcd…" }
}

events

Your auth system should speak your language.

Every request becomes a trace; every change becomes an audit event. Read them from the dashboard, the management API, or an MCP client — or have them pushed to you as signed webhooks.

  • Signed webhooksHMAC-SHA-256 over timestamp and body, retried with exponential backoff
  • Management API/api/v1/traces and /api/v1/events with scoped tokens
  • MCP toolslist_authorization_traces, get_authorization_trace
  • Request IDsx-request-id on every response, for your own logs

Interactive example · demo data

productiontraces and audit events

authorization_request
GET /api/v1/traces/req_Hd4sZ0rWb2
authorization: Bearer amt_…

{
  "request_id": "req_Hd4sZ0rWb2",
  "status": "denied",
  "event_type": "authorization_request",
  "application_name": "Itsagram Web",
  "client_id": "itsagram-web",
  "started_at": "2026-09-28T16:12:15.285Z"
}

Event types and payload fields match what Authometry records and delivers. Webhooks carry audit and security events; traces are read through the API and MCP.

security

Secure because the behavior is explicit.

No badges, no adjectives. These are the controls in the code, stated precisely enough to verify.

Read the security model(opens in a new tab)

Protocol

PKCE
S256 only. Public clients must send a challenge.
Redirect URIs
Complete, exact matching. HTTPS unless the host is localhost.
Authorization codes
Single use, 60 s by default, bound to client, redirect URI, user, scopes, and challenge.
Refresh tokens
Rotate on every use. Reuse revokes the whole family and records a high-severity event.
Revocation
Non-enumerating: unknown tokens still receive success.

Keys and secrets

Signing keys
One active RS256 key per environment. Rotated keys stay in JWKS until they retire.
Stored credentials
Passwords with bcrypt (cost 12). Codes, refresh tokens, and client secrets as HMAC-SHA-256 digests.
Encrypted at rest
Private signing keys and webhook secrets with AES-256-GCM.
Trace redaction
Fields named like tokens, codes, secrets, cookies, passwords, or assertions are replaced before storage.

Operations

Environments
Separate issuers, keys, applications, and policies for each.
Configuration
Applied in one transaction under an advisory lock, with deployment provenance.
Dashboard sessions
HTTP-only cookies, signed double-submit CSRF, 10-minute access tokens.
Rate limits
30 credential attempts per 15 minutes; 120 token requests per minute.
Webhooks
HTTPS only. Private and reserved addresses are rejected at delivery time.

source

Your identity layer. Your infrastructure.

Authometry is open source and self-hosted. The code that evaluates a policy, signs a token, or redacts a trace is the code you can read, run, and change.

View source on GitHub(opens in a new tab)Deployment guide(opens in a new tab)
License
AGPL-3.0-only
Runs as
Web and server images on Node.js 24
Data
Your PostgreSQL database
Configuration
YAML manifests, exportable
Protocols
OAuth 2.0 and OpenID Connect only

Your applications

  • itsagram-web
  • api.itsagram.com
  • MCP clients
  • authometry CLI
OAuth 2.0 / OIDCManagement API

Your network

Authometry

Web origin Next.js :3000

Dashboard, sign-in, consent, and device pages. Rewrites protocol paths.

Protocol and API server Express :4000, private

  • Authorization server/oauth/*, discovery, JWKS
  • Policy engineconditions per application
  • Trace recorderredacted, per request
  • Management API/api/v1, personal tokens
  • MCP server/mcp, OAuth-scoped tools
  • Workerswebhooks, retention, key expiry
PostgreSQLSource of truth. Secrets stored as hashes or AES-256-GCM.
Webhook endpointsHMAC-signed deliveries
SMTPOptional, for invites and resets
Runtime topology from the repository’s architecture guide. Only the web origin faces the internet.

philosophy

An error code is not an explanation.

OAuth errors are deliberately terse on the wire — clients shouldn’t learn your configuration. Operators should. Authometry keeps both views.

What the client seesWhat Authometry records
error=access_deniedpolicy_deniedPolicy Workspace member denied the request.user.groups did not contain "bellaire-media". Message: A Bellaire Media workspace account is required.
400 redirect_uri_mismatchredirect_uri_mismatchThe requested redirect URI is not registered for Itsagram Web.Received https://itsagram.com/callback. Registered https://itsagram.com/auth/callback.
error=invalid_requestpkce_requiredThis application requires an S256 code challenge.Generate a code verifier and send its S256 challenge with the authorization request.
400 invalid_grantrefresh_token_reuseA rotated refresh token was reused. The token family was revoked.Recorded as a high-severity security event in the audit log.
  1. 01Standards over lock-in.
  2. 02Configuration over mystery.
  3. 03Evidence over assumptions.
  4. 04Decisions should be explainable.
  5. 05Infrastructure should be inspectable.
Authometry

Open-source OAuth 2.0 and OpenID Connect infrastructure you can inspect.

Product

  • How it works
  • Authorization traces
  • Debugging denials
  • Platform reference
  • Standards
  • Agents and MCP

Developers

  • Documentation
  • Quickstart
  • Integration
  • Manifests and CLI
  • MCP server
  • Webhooks
  • API reference(opens in a new tab)

Project

  • Source(opens in a new tab)
  • Contributing(opens in a new tab)
  • Security controls
  • Security model(opens in a new tab)
  • CLI on npm(opens in a new tab)
  • AGPL-3.0 license(opens in a new tab)

Access

  • Console sign in
  • Employee portal
  • Privacy
  • Terms

Authentication, measured.

© 2026 Authometry contributors

Authometry