What is Sudomimus
Sudomimus is an authentication and authorization platform designed to be embedded into web, desktop, native, and OIDC-compatible applications. It provides a unified way to:
- Authenticate end users via multiple methods — passkeys (WebAuthn), email one-time passwords, social sign-in (Google, GitHub, Discord, Battle.net, X), Steam (in-game ticket or “Sign in with Steam”), and AccessKey credentials for headless clients — with more being added over time.
- Exchange short-lived tokens through the Connect flow, device authorization, native direct-issue, or standard OIDC.
- Act as a standard OpenID Connect provider for relying parties that prefer
authorization_code+ PKCE over the Connect protocol. - Manage users by domain — claim a domain you own, then decide platform-wide how its users authenticate: allow, block, or force them through your own identity provider.
- Enforce authorization rules on protected resources through a three-layer allowlist model, so each application does not have to reimplement them.
Why Sudomimus
Section titled “Why Sudomimus”Most applications end up reinventing the same authentication primitives: session storage, password resets, email verification, social login, MFA. Sudomimus separates the identity layer from the application layer, so the authentication surface lives in one place and your application only deals with verified tokens.
The five public surfaces
Section titled “The five public surfaces”Sudomimus exposes five public surfaces to integrators:
| Domain | Audience | Purpose |
|---|---|---|
connect-api.sudomimus.com | Application backend | The Connect protocol — establish, redeem, refresh, introspect, logout, revoke. |
via.sudomimus.com | End users in a browser | The hosted page that runs the user-facing authentication flow. |
device-api.sudomimus.com | Public clients (CLIs, launchers, shared devices) | Device authorization — code confirmation and polling for public clients without a client secret. |
native-api.sudomimus.com | Native clients (desktop apps, games, CLIs) | Steam direct-issue and AccessKey direct-issue — one-shot login for clients with no browser. |
oidc.sudomimus.com | OIDC relying parties | Standard OpenID Connect provider — discovery, authorize, token, userinfo, JWKS. |
You’ll typically pick one of Connect, OIDC, device authorization, or native direct-issue. Choose an integration path compares them.
Where to go next
Section titled “Where to go next”- Building a web app with Connect? Start with the Quickstart, then the Connect flow.
- Building a CLI, launcher, or public client? Go to Device authorization.
- Integrating a desktop app, game, or client with Steam/AccessKey credentials? Go to Native integration.
- Wiring up an OIDC relying party? Go to the OIDC flow.
- Want to understand the shared model first? Read Authentication philosophy and Accounts and credentials.
Registering your application
Section titled “Registering your application”Applications are created and managed through the developer portal at with.sudomimus.com — that is where you obtain your applicationAnchor, retrieve the client-auth private key (shown once at creation), and configure the three layers of rules. Quickstart links to the exact pages.