NazoAuth

OAuth 2.0 and OpenID Connect, written in Rust.

Deploy · Certifications · Connect an application · Protocol status · 简体中文

NazoAuth runs sign-in, token issuance, and client access under your own issuer. It includes passkeys, MFA, tenant routing, and external identity providers. Its protocol and business cores access persistent and transient state through storage interfaces. Concrete adapters provide the storage implementation.

Warning

Before 0.5.0, this project iterates rapidly. Version updates do not preserve compatibility with historical releases. Configuration, stored state, administrative interfaces, and control messages follow the current format. Back up a deployment before upgrading and follow the target release's setup requirements. Historical format readers and conversion layers are not maintained.

OpenID Certified

The OpenID Foundation's public certification directory lists NazoAuth / Nazo Auth Server 0.2.0 for the following 29 conformance profiles. Each link opens the official register, including the certification and test-result records.

Certification	Certified profiles	Registered
OpenID Provider	Basic OP · Config OP · Form Post OP · 3rd Party-Init OP	2026-07-29
OpenID Connect Logout	RP-Initiated OP · Session OP · Front-Channel OP · Back-Channel OP	2026-07-29
FAPI 2.0 Security Profile Final	FAPI2SP OP MTLS + MTLS FAPI2SP OP MTLS + DPoP FAPI2SP OP private key + MTLS FAPI2SP OP private key + DPoP FAPI2SP OP OpenID Connect	2026-07-29
FAPI 2.0 Message Signing Final	FAPI2MS OP JAR · FAPI2MS OP JARM	2026-07-29
FAPI 2.0 Client Credentials	FAPI2SP OP Client Credentials MTLS + MTLS FAPI2SP OP Client Credentials MTLS + DPoP FAPI2SP OP Client Credentials private key + MTLS FAPI2SP OP Client Credentials private key + DPoP	2026-07-29
FAPI-CIBA	FAPI-CIBA OP Poll w/ MTLS FAPI-CIBA OP Poll w/ Private Key FAPI-CIBA OP Ping w/ MTLS FAPI-CIBA OP Ping w/ Private Key	2026-07-29
OID4VCI 1.0 + HAIP 1.0	OID4VCI-1.0+HAIP-1.0 Issuer sd_jwt_vc issuer_initiated OID4VCI-1.0+HAIP-1.0 Issuer sd_jwt_vc wallet_initiated OID4VCI-1.0+HAIP-1.0 Issuer mdoc issuer_initiated OID4VCI-1.0+HAIP-1.0 Issuer mdoc wallet_initiated	2026-08-21
OID4VP 1.0 + HAIP 1.0	OID4VP-1.0+HAIP-1.0 Verifier sd_jwt_vc direct_post.jwt OID4VP-1.0+HAIP-1.0 Verifier iso_mdl direct_post.jwt	2026-08-23

The OID4VCI and OID4VP registers spell the implementation version v0.2.0. The certification mark and scope above refer to these registered deployments.

What it handles

Area	Capabilities
Application access	Authorization Code with PKCE, client credentials, rotating refresh tokens, token introspection and revocation, device authorization, CIBA poll/ping
Request and token protection	PAR, JAR, JARM, DPoP, mTLS, per-client security policy, FAPI 2.0 controls
Sign-in	Passwords, passkeys, TOTP MFA, external OIDC providers, QQ/WeChat adapters, a trusted SAML gateway
Tenants	Host-based issuer routing, tenant-scoped service graphs, signing keys, clients, sessions, and storage
Identity administration	Account profiles, client and grant management, SCIM provisioning, security events
Digital credentials	OpenID4VCI issuance and OpenID4VP presentation, with configured credential profiles and trust material

A published capability still needs client authorization. The capability policy describes defaults, prerequisites, and per-client controls. Implicit, hybrid, password grants, unsigned Request Objects, and CIBA push are not supported.

Deploy

Use NazoAuthCtl to install and operate a release on a local or SSH host. Choose Docker, Podman, or a host binary. The current distribution uses the PostgreSQL and Valkey adapters. Prepare a public HTTPS issuer, PostgreSQL with separate runtime and lifecycle roles, and Valkey.

Install on an SSH host

Install NazoAuthCtl on both ends first; the remote helper must match the controller build. Use an existing OpenSSH alias and replace the release-tag placeholder with the signed release you intend to deploy.

nazoauthctl host add production-host --ssh production --privilege sudo

nazoauthctl install \
  --host production-host --name production \
  --to '<nazoauth-release-tag>' \
  --runtime podman --public-url https://auth.example.com \
  --database-host db.internal --database-port 5432 \
  --database-name nazoauth \
  --database-runtime-user nazo_runtime \
  --database-runtime-password-file ./database-runtime-password \
  --database-lifecycle-user nazo_lifecycle \
  --database-lifecycle-password-file ./database-lifecycle-password \
  --valkey-host valkey.internal --valkey-port 6379 \
  --valkey-password-file ./valkey-password

nazoauthctl admin create --instance production

Sign in at https://auth.example.com/ui/auth and enroll MFA. Then bind the controller using that administrator account:

nazoauthctl bind --instance production --label operations \
  --output-secret-file ./production-recovery-secret
nazoauthctl verify --instance production

Keep the recovery secret offline. The first administrator is created through the target's local deployment authority; controller binding requires that administrator and fresh MFA approval.

The installation guide covers the full sequence, backup verification, updates, and recovery. Deployment covers TLS, reverse proxies, and health checks. External databases and Valkey remain under your administration.

Connect an application

Start with the issuer's discovery document:

https://auth.example.com/.well-known/openid-configuration

Register a client and its exact redirect URIs, then use Authorization Code with S256 PKCE. The OIDC integration guide covers registration, discovery, authorization, tokens, and logout.

Each client has an explicit security policy. Enable the grants and token protection that the application needs; enabling a server module does not grant every client access to it.

Inside the server

One executable composes the protocol cores, identity services, and adapters. The cores depend on semantic persistence and state interfaces; adapters implement those contracts and own driver calls, transactions, and storage mechanics.

flowchart TB
    Core["Protocol and identity cores"] --> Ports["Persistence and state interfaces"]
    PG["PostgreSQL adapter"] -. persistence .-> Ports
    VK["Valkey adapter"] -. transient state .-> Ports

Loading

PostgreSQL and Valkey are the currently implemented adapters, not requirements of the core architecture. The composition root selects them; the protocol and business crates do not depend on their drivers. Avatar storage has separate local and S3-compatible adapters.

Tenant selection happens before request handlers run. Each active tenant has its own service graph and signing-key lifecycle. Host routing uses an immutable in-process index; unknown hosts are rejected. See architecture and tenant boundaries for the ownership rules.

Development and verification

Use the repository's pinned Rust toolchain. Tests that exercise PostgreSQL, Valkey, and object storage need the isolated services and fixture configuration defined in the quality workflow.

cargo build --release --locked
cargo fmt --all -- --check
cargo clippy --workspace --all-targets --all-features --locked -- -D warnings
cargo test --workspace --all-features --locked

Testing explains the checks and external test setup. Conformance records identify the artifacts and conditions covered by project regression runs. Official certification profiles and registration dates are listed in OpenID Certified.

Documentation

Build an integration	Operate a deployment
OIDC integration	Configuration
Passkeys · MFA	Deployment and TLS
Identity federation	High availability
SCIM	Security model
Protocol coverage	Performance measurements

Report vulnerabilities through SECURITY.md. Contribution rules are in CONTRIBUTING.md.

Licensed under AGPL-3.0-or-later. Commercial licensing requires a separate agreement.