Syntropy Auth

Syntropy Auth is the identity layer built into the Syntropy platform. It is a full OAuth 2.0 / OpenID Connect provider that your product can use as a drop-in replacement for Auth0, Clerk, or any other third-party identity service.

What it gives you

Feature	Description
Email / password	Signup, login, email verification, password reset
Social login	Google, GitHub, Microsoft, Discord — configurable per OAuth client
MFA	TOTP (authenticator apps); WebAuthn / Passkeys ready
Standard protocols	Full OIDC / OAuth 2.0 with PKCE, token introspection, JWKS, discovery
Hosted UI	Server-rendered login, signup, and consent pages — no frontend work required
Project-scoped auth	User pools isolate users per project or org — same email can exist independently in different pools
Embeddable SDKs	Next.js adapter, Express middleware, framework-agnostic core client
CORS allowlist	Per-client origin allowlist — only registered origins can make cross-origin requests to the auth service

Architecture at a glance

┌─────────────────┐     OIDC redirect      ┌──────────────────┐
│   Your Product  │ ─────────────────────► │  Syntropy Auth   │
│  (Next.js app)  │                        │  (apps/auth)     │
│                 │ ◄───────────────────── │                  │
│  auth-next SDK  │    access + id tokens  │  oidc-provider   │
└─────────────────┘                        │  Hono / Drizzle  │
                                           └──────────────────┘

Your product registers as an OAuth client in the Syntropy dashboard. When a user logs in, they are redirected to Syntropy Auth's hosted login page, authenticate, and are sent back with an authorization code that your app exchanges for tokens. Syntropy Auth never shares credentials with your product — it only shares identity claims (user ID, email, name).

Key concepts

User pool — The isolation boundary for users. Each pool has its own set of users, credentials, and email uniqueness constraint. Pools can be owned by an organization (shared across projects in that org) or by an individual project (fully isolated). Two users with the same email in different pools are completely independent — no cross-pool SSO unless the auth client is org-scoped.

OAuth client — Represents your product (or a specific deployment of it). Each client belongs to a user pool. Configured in the Syntropy dashboard with:

• User pool — which pool this client authenticates against
• Redirect URIs — where Syntropy Auth sends users after login
• Allowed origins — frontend origins permitted to make cross-origin requests (CORS allowlist)
• Allowed scopes — which OIDC claims the client can request (openid, profile, email, org)
• Social connections — upstream OAuth providers (Google, GitHub, etc.) enabled for this client

User — A Syntropy Auth user account scoped to a user pool. Users are owned by the auth service, not by your product. Your product stores a reference (syntropyAuthId) and retrieves claims from the userinfo endpoint or the ID token.

Social connection — An upstream OAuth provider (Google, GitHub, etc.) linked to an OAuth client. Users authenticating via a social provider are automatically linked to or created as Syntropy Auth users within the client's user pool.

PKCE — Proof Key for Code Exchange. All OAuth flows use PKCE. The SDKs handle this automatically.

Deployment

Syntropy Auth runs as a separate Hono service (apps/auth) alongside the main web app. It exposes:

• GET/POST /auth/interaction/:uid — Hosted login / signup / consent UI
• GET /auth/callback/:provider — Social login callbacks
• GET/POST /auth/password-reset — Password reset flow
• POST /auth/mfa/* — MFA enrollment and verification API
• /oauth/* — OAuth 2.0 endpoints (delegated to oidc-provider)
• /.well-known/openid-configuration — OIDC discovery
• /.well-known/jwks.json — Public key set

See Quick Start to integrate Syntropy Auth into your product.