---
title: What is Sudomimus
description: A high-level overview of the Sudomimus authentication and
  authorization platform.
editUrl: true
head: []
template: doc
sidebar:
  order: 1
  hidden: false
  attrs: {}
pagefind: true
draft: false
---

**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](/en-us/domains-federation/adopt-a-domain/), then decide platform-wide how its users authenticate: allow, block, or [force them through your own identity provider](/en-us/domains-federation/sign-in-with-your-idp/).
- Enforce **authorization rules** on protected resources through a three-layer allowlist model, so each application does not have to reimplement them.

## 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

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](/en-us/getting-started/choose-integration/) compares them.

## Where to go next

- Building a **web app with Connect**? Start with the [Quickstart](/en-us/getting-started/quickstart/), then the [Connect flow](/en-us/connect/flow/).
- Building a **CLI, launcher, or public client**? Go to [Device authorization](/en-us/device/flow/).
- Integrating a **desktop app, game, or client with Steam/AccessKey credentials**? Go to [Native integration](/en-us/native/overview/).
- Wiring up an **OIDC relying party**? Go to the [OIDC flow](/en-us/oidc/flow/).
- Want to understand the shared model first? Read [Authentication philosophy](/en-us/concepts/philosophy/) and [Accounts and credentials](/en-us/concepts/accounts-and-credentials/).

## Registering your application

Applications are created and managed through the developer portal at [`with.sudomimus.com`](https://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.