Identityv1.1.1

🔑authx-identity is the identity authority your applications don't have to build.

Give identity its own boundary.

Every application eventually needs identity: users need to sign in, credentials need protecting, tokens need issuing and refreshing. Left alone, every application ends up building that infrastructure itself — one more password table, one more token signer, one more SSO integration. AuthX takes a different approach: a standalone identity authority that centralizes authentication, identity, and token authority while applications remain independent owners of their own business domains. AuthX answers "who authenticated?"; the application still answers "what can this identity do here?" — a clean boundary between identity and domain.

OIDC

Standards-Based Contract

RSA

Signed JWTs + JWKS

Explicit Trust Boundaries

1:N

Authority → Applications

PyPI Package Source Documentation

authx-identity

Live

$pip install authx-identity

pip install · no build step · drop into any Python project

What's New

Why It Exists

Authentication logic spreads across every service by default — each one ends up owning its own password storage, token signing, and session state.
Every new application means reinventing login, token issuance, and revocation instead of consuming a trusted identity authority.
Without an explicit boundary, an identity service tends to grow into a shared application database — accumulating profiles, roles, and business data it was never meant to own.
Mixing public authentication with privileged identity-management operations blurs a trust boundary that should be explicit and enforced.

Two APIs. Two trust levels.

Public Auth API — untrusted clients

OIDC discovery
Token issuance & refresh
UserInfo
JWKS (public verification keys)

Internal Identity API — trusted services

Authenticated via X-Service-Token
Backend user administration
Never exposed to browsers or public clients

One authority, explicit trust boundaries

What authx-identity Does

Centralized Identity Authority: UserIdentity is the single authoritative record for who a user is — credential state, SSO linkage, verification, and account lifecycle all live in one place instead of being duplicated per app.
RSA-Signed JWTs & JWKS: AuthX signs access tokens with an RSA private key it never exposes; consumers verify signatures independently against the public /jwks endpoint.
Stateful Refresh, Stateless Access: Access tokens stay stateless for cheap verification; refresh tokens are tracked server-side so rotation, expiration, and revocation are fully controllable.
OIDC-Oriented Public Surface: Discovery, /token, /token/refresh, /userinfo, and /jwks give consuming apps a recognizable authentication contract instead of a bespoke protocol.
Explicit Trust Boundaries: A public, untrusted client surface is kept structurally separate from an internal, service-token-authenticated identity-management API.
Credentials Never Leave the Boundary: Passwords are hashed on arrival and never reproduced in API responses — consuming apps authenticate users without ever touching password storage.
Django Client Included: The distribution ships authx_client alongside the service itself, so Django/Python applications can authenticate against AuthX and verify tokens locally without coupling their domain models to the identity service.

FastAPIOIDC / OAuth2JWTIdentity Authority

Install & Quickstart

Install

pip install authx-identity

Request an access & refresh token

POST /token
content-type: application/x-www-form-urlencoded

grant_type=password&username=<user>&password=<pass>

Fetch the authenticated user

GET /userinfo
Authorization: Bearer <access_token>

Verify tokens with the public signing key

GET /jwks

Trusted backend calls the internal identity API

GET /internal/identity/users/<id>
X-Service-Token: <AUTHX_SERVICE_TOKEN>

Security & Trust Boundaries

Passwords are hashed on arrival and never reproduced through the API — AuthX owns credential storage end-to-end.
Access tokens are signed with an RSA private key that never leaves AuthX; consumers verify independently via the public JWKS endpoint.
Refresh tokens are tracked server-side, enabling rotation, expiration, and revocation instead of trusting a token indefinitely.
Trusted backend services authenticate to the internal identity API with a dedicated service token — never with end-user credentials.
Issuer/audience validation and restricted CORS origins keep the token contract from being silently reused where it shouldn’t be.

Own identity once.

Let every application consume it.

One identity authority · Explicit trust boundaries · Standards-based tokens

Install authx-identity View Source