Docs/Reference

HTTP and RPC API

Browser-facing JSON, binary dashboard RPC and private native gRPC—each with a deliberately different trust model.

WebAuthnHTTP + JSON

Web dashboardConnect + Protobuf

Trusted servicesgRPC + Protobuf

Browser HTTP

Passkey ceremonies remain HTTP-oriented because browsers own the WebAuthn APIs. Exact-origin checks, server-side single-use ceremonies and secure HttpOnly session cookies protect this boundary. JSON access tokens are short-lived and belong in memory—not local storage.

GET/healthzPublic

Process liveness

GET/readyzPublic

Private datastore readiness

GET/.well-known/jwks.jsonPublic

ES256 verification keys

POST/v1/passkeys/registration/optionsOrigin + bootstrap

Start first registration

POST/v1/passkeys/registration/verifyOrigin + bootstrap

Finish first registration

POST/v1/passkeys/authentication/optionsOrigin

Start sign-in

POST/v1/passkeys/authentication/verifyOrigin

Finish sign-in

POST/v1/tokenSession + origin

Mint short-lived JWT

GET/v1/accountSession + origin

Read identity profile

GET/v1/credentialsSession + origin

List passkey metadata

POST/v1/sign-outOrigin

Revoke current session

Dashboard RPC

The Dioxus web dashboard calls Connect-compatible Protobuf services and carries its secure session cookie automatically. The server still enforces origin, CSRF, operator scope and tenant hierarchy on every request. Browser compatibility is the reason to use Connect or gRPC-Web at this edge rather than unrestricted native gRPC.

Trusted service RPC

rustyauth.identity.v1.IdentityService provides safe reads, exact search and controlled profile, identifier and passkey mutations. Short-lived service-account JWTs enforce identity.read or identity.write by exact method; identifier verification remains operator-only. Native clients use gRPC/HTTP2 with TLS and narrowly scoped credentials; deployments should prefer mTLS or workload identity at the network boundary.

Standalone metrics

rustyauth.metrics.v1.MetricsService serves bounded per-realm overview, series, authentication-funnel and failure-breakdown calls to authenticated operators. Responses exclude user, contact, IP, credential and webhook URL dimensions.

Fleet Analytics interchange

rustyauth.analytics.v1 defines validated metric-bucket batches, exact acknowledgements, coverage and signed archive manifests. Realms export complete revisions over the authenticated RealmConnectorService after local projection and durable queuing. The dedicated Analytics service serves bounded fleet, organization, project, environment and realm queries from private canonical and materialized GreptimeDB data; Dioxus never sends SQL. See Fleet Analytics V1 for the compatibility contract and Fleet Analytics for its supported tier and continuous assurance program.

Events and discovery

rustyauth.events.v1.AuthEventService supports replay-then-follow server streaming for service accounts with events.read. Public discovery exposes the issuer, supported browser capabilities and active/staged verification keys. Backup health, operator state and private credentials are deliberately excluded from unauthenticated discovery. See the authentication events guide for a working profile-sync flow.

Webhook contract and IaC ownership

rustyauth.webhooks.v1.WebhookService serves destination management, one-time signing-secret creation and rotation, tests, delivery history and replay to operators or service accounts with webhooks.manage. A Webhook's managementSource distinguishes dashboard-managed resources from configuration-managed resources declared under spec.webhooks. Clients must render configuration-managed destination fields read-only and direct edits or deletion back to YAML.

Durable delivery is supported in 1.0.0: exact bodies are signed with HMAC-SHA256, retryable failures use bounded backoff, redirects are disabled and retained source events can be replayed. Pin the exact release or image digest you operate.

Error behavior

Invalid origins, consumed ceremonies, expired sessions, unknown credentials and unavailable durable state fail explicitly. Clients must not interpret an empty success response as degraded security state.