PRX Identity id.prx.is

PRX Identity

Centralized OAuth and signed identity tokens for PRX infrastructure. Issues a stable opaque UUID per subject; Security gates access on that UUID.

Live v0.0.0 · 2026-08-31T01:45:35.523Z /healthz JSON

Active signing key Live · M2

kid
id-kK7I3KKULvsA
alg
EdDSA (Ed25519)
loaded
2026-05-10T03:20:17.798Z
jwks
/jwks.json
discovery
/.well-known/openid-configuration

What works today

  • Health endpoint Live · M0 GET /healthz — JSON heartbeat.
  • User-facing pages Live · M1 Sign-in, account, admin, lookup — server-rendered HTML.
  • Public signing keys Live · M2 GET /jwks.json — Ed25519 keys consumers use to verify tokens offline.
  • OIDC discovery Live · M2 GET /.well-known/openid-configuration.
  • Google sign-in Live · M3 Federated sign-in via Google.
  • Microsoft sign-in Live · M3 Federated sign-in via Microsoft.

What's planned

  • Identity token issue (humans) M4 POST /token authorization_code grant; returns signed JWT.
  • prx.is integration M5 prx.is uses Identity for sign-in; existing users backfilled.
  • Service identities M6 Registered Ed25519 keypairs for CLIs, cron, and internal scripts.
  • Identity token issue (services) M6 POST /token client_credentials with JWT-bearer client assertion.
  • Apple sign-in M7 Federated sign-in via Apple.
  • Attribute lookup M7 GET /lookup/<uuid> — mutable attributes (display_name, last-known email).

Roadmap

How a service trusts an Identity token

  1. Service redirects the user to /authorize.
  2. Identity federates to Google / Microsoft / Apple, gets back a verified email.
  3. Identity looks up or creates a stable UUID for the user.
  4. Identity hands the service an authcode; the service exchanges it at /token for a signed JWT.
  5. Service verifies the JWT signature against /jwks.json (cached locally; offline check). Trusts sub, ignores everything mutable.
  6. Service creates its own session cookie, scoped to its own domain. Identity never sees that cookie.