What is Sudomimus
Sudomimus is an identity provider and authentication 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.
- Apply a three-layer allowlist to session admission and identity disclosure. Integrating applications remain responsible for their own business roles, permissions, resources, and authorization policy.
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.
Public integration surfaces
Section titled “Public integration surfaces”Sudomimus exposes these public surfaces to integrators:
| Domain | Audience | Purpose |
|---|---|---|
connect-api.sudomimus.com |
Application backend | The Connect protocol — establish, status-poll, redeem, info. |
session-api.sudomimus.com |
Applications holding refresh tokens | Ordinary application session lifecycle — 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, AccessKey, and PublicKey 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/PublicKey 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, receive the application-creation client-auth private key, and configure the three layers of rules. The private key is not available from ordinary application reads; an unchanged uncertain-result retry can recover the exact create result for ten minutes. Quickstart links to the exact pages.