中文文档 · Documentation · Quick start · Security
Nazo Auth Server is a self-hosted OAuth 2.x / OAuth 2.1-aligned and OpenID Connect authorization server written in Rust. It is built for same-origin deployments where the issuer, browser UI, passkeys, CORS, cookies, and protocol endpoints share one public origin.
The project includes the authorization server, a compact identity/admin surface, local signing key management, WebAuthn/passkeys, MFA, SCIM, and Rust resource-server verification libraries. Modular external-provider login is tracked in the future roadmap rather than advertised as a current default capability. It uses PostgreSQL for durable state and Valkey for short-lived protocol state.
NazoAuth predates OpenAI Build Week. The hackathon submission covers only the
work completed after the submission period opened at
2026-07-13T16:00:00Z. The last pre-period commit is
ef7df3e,
and the complete review range is
ef7df3e..main.
During the submission period, Codex with GPT-5.6 helped turn the existing server into a modular Rust workspace, implement OpenID4VC Final issuer and verifier roles, add FAPI-CIBA mTLS/ping and RFC 9967 SCIM security-event delivery, harden the browser client and onboarding flow, and make the official OIDF suites exercise the public production service as a black box. Codex accelerated repository audits, implementation, tests, specification cross-checks, CI diagnosis, and deployment verification. The maintainer chose the product and security boundaries, required standards-first behavior instead of suite-specific shortcuts, reviewed the changes, and controlled deployment and merge decisions.
See the Build Week engineering record for the before/after boundary, dated pull requests, measured change volume, Codex collaboration details, setup instructions, and a no-rebuild public test path. The live demo is available at https://auth.nazo.run/ui/auth.
| Item | Value |
|---|---|
| Package | nazo-oauth-server |
| Version | 0.1.0 |
| License | AGPL-3.0-or-later |
| Language | Rust 2024 |
| Runtime services | PostgreSQL, Valkey |
| Conformance test issuer | operator-provided public HTTPS origin |
| Default deployment model | same-origin |
Project quality is tracked through direct, auditable checks rather than a composite score:
| Signal | Evidence |
|---|---|
| Rust quality gate | cargo fmt --check, cargo check --workspace --all-targets --all-features --locked, cargo clippy -D warnings, migrations, and the complete workspace test suite in code-quality. |
| Static security analysis | CodeQL Rust analysis with the security-extended query suite. |
| Dependency policy | GitHub dependency review, cargo audit, and cargo deny over advisories, bans, licenses, and sources. |
| Runtime security behavior | Real HTTP E2E, load/race gate, and Valkey outage injection in conformance-security. |
| Protocol conformance | Public black-box official-suite evidence for the current 25-plan OIDF/FAPI matrix and 17-plan OpenID4VC matrix. |
| Coverage trend | Codecov LCOV upload from the dedicated coverage workflow. |
| Release provenance | CycloneDX SBOM, Trivy image scan, Sigstore signing, and GitHub artifact attestations. |
📚 Standards and profile support
🏅 Certification and conformance evidence
- Authorization code + PKCE, refresh tokens, client credentials, bounded JWT bearer grant, bounded Token Exchange, revocation, introspection, signed/encrypted introspection, discovery, protected resource metadata, JWKS, JSON/signed/encrypted UserInfo, signed/encrypted JARM, PAR, JAR, DPoP, and mTLS.
- Runtime profiles:
oauth2-baseline,fapi2-security,fapi2-message-signing-authz-request,fapi2-message-signing-jarm, andfapi2-message-signing-introspection. - Local users, profiles, OAuth clients, grants, access requests, TOTP MFA, backup codes, remembered MFA, WebAuthn/passkeys, and SCIM provisioning.
- Local signing key lifecycle with prepublish, active, grace, and retired states. External-command signing is available for KMS/HSM integrations.
- Framework-independent Rust resource-server verifier plus the project's Actix HTTP integration. Historical Axum/Tower and tonic adapters are not shipped.
- Release security workflows for CodeQL, dependency review, cargo audit, cargo deny, SBOM generation, Trivy image scanning, keyless signing, and provenance attestations.
Requirements:
- The exact Rust stable version pinned by
rust-toolchain.toml - PostgreSQL 18 or a compatible PostgreSQL server
- Valkey 8 or a compatible Redis protocol server
- Container runtime for the optional integration stack
Run with Docker Compose:
cp .env.yaml.example .env.yaml
docker compose up -d nazo_oauth_server
curl -fsS http://127.0.0.1:8000/health
curl -fsS http://127.0.0.1:8000/.well-known/openid-configurationRun directly on the host after pointing .env.yaml at reachable PostgreSQL and
Valkey services:
cargo run --bin nazo-oauth-migrate
cargo run --bin nazo-oauth-serverConfiguration is intentionally small for new deployments:
BIND: "0.0.0.0:8000"
PUBLIC_BASE_URL: "https://auth.example.com"
DATABASE_URL: "postgresql://nazo_oauth:<password>@postgres:5432/oauth"
VALKEY_URL: "redis://valkey:6379/0"
DATA_DIR: "/var/lib/nazo_oauth"
AUTHORIZATION_SERVER_PROFILE: "oauth2-baseline"
RUST_LOG: "info"PUBLIC_BASE_URL drives the same-origin defaults:
| Value | Default rule |
|---|---|
ISSUER |
PUBLIC_BASE_URL |
FRONTEND_BASE_URL |
PUBLIC_BASE_URL + "/ui/" |
CORS_ALLOWED_ORIGINS |
origin of PUBLIC_BASE_URL |
COOKIE_SECURE |
true for HTTPS issuers |
PASSKEY_ORIGIN and PASSKEY_RP_ID |
derived from issuer |
PROTECTED_RESOURCE_IDENTIFIER |
ISSUER + "/fapi/resource" |
DATA_DIR drives persistent local file paths:
| Value | Default rule |
|---|---|
JWK_KEYS_DIR |
DATA_DIR + "/keys" |
AVATAR_STORAGE_DIR |
DATA_DIR + "/avatars" |
Advanced settings cover specialized deployments. They are documented in docs/operations/configuration.md.
The following capabilities are outside the default authorization-server surface and are not advertised unless implemented, tested, and explicitly enabled:
- Dynamic Client Registration / RFC 7591 and Client Configuration Management
/ RFC 7592 unless
ENABLE_DYNAMIC_CLIENT_REGISTRATION=true; public registration deployments should protect/registerwith an initial access token. - Device Authorization Grant / RFC 8628 unless
ENABLE_DEVICE_AUTHORIZATION_GRANT=true. - External-token, refresh-token, or ID-token Token Exchange profiles.
- Modular third-party login providers such as QQ, WeChat, Google, Microsoft, or enterprise SAML; these are roadmap items until provider-specific adapters, configuration gates, account linking, and E2E/negative tests exist.
- Request-level dynamic tenant or issuer routing.
- RFC 9701 encrypted introspection responses outside the signed-introspection profile, or without per-client JWE response metadata.
- UserInfo or JARM encryption without supported per-client JWE metadata and a unique matching public encryption key.
See docs/project/roadmap.md for the current scope record.
cargo fmt --check
cargo check --workspace --all-targets --all-features --locked
cargo clippy --workspace --all-targets --all-features --locked -- -D warnings
cargo test --workspace --all-features --lockedHTTP and concurrency checks:
python scripts/full_real_request_e2e.py
python scripts/full_real_request_load.pyCoverage runs are documented in docs/coverage/codecov-docker-runbook.md.
The public source code is licensed under AGPL-3.0-or-later. This applies equally to individuals and organizations. A separate commercial license may be available for qualifying closed-source use, but is granted only by a signed agreement with the applicable copyright holders. See COMMERCIAL-LICENSE.md and CONTRIBUTING.md.