OIDC Provider
The OIDC provider side of authx-rs lets your application act as the identity provider for other apps, SPAs, CLIs, and services.
What it exposes
Section titled “What it exposes”The Axum integration provides standard endpoints under the OIDC router:
- discovery:
/.well-known/openid-configuration - authorization:
/authorize - token:
/token - userinfo:
/userinfo - JWKS:
/jwks - introspection:
/introspect - revocation:
/revoke - device authorization:
/device_authorization
Supported flows
Section titled “Supported flows”Authorization code
Section titled “Authorization code”For browser and server-side clients. Public clients can use PKCE; confidential clients can use a client secret.
Refresh token
Section titled “Refresh token”Longer-lived refresh tokens can mint new access tokens without forcing the user through another login.
Device authorization
Section titled “Device authorization”For CLIs and input-constrained devices. authx-rs issues a device code and user code, then the user completes verification in a browser session.
Storage model
Section titled “Storage model”The provider uses dedicated repository traits for:
- registered OIDC clients
- authorization codes
- OIDC tokens
- device codes
That keeps the protocol logic in authx-plugins while allowing different backends in authx-storage.
Security model
Section titled “Security model”- client secrets are stored hashed, not raw
- authorization codes are single-use and short-lived
- PKCE is supported for public clients
- access tokens are JWTs signed through
KeyRotationStore - refresh tokens are opaque and stored hashed
When to use it
Section titled “When to use it”Use authx-rs as an OIDC provider when:
- you want your own apps to trust a central authx deployment
- you need standard OAuth/OIDC interoperability instead of custom session APIs
- you want device-code support for CLI or TV-style clients