Authentication philosophy

Sudomimus treats every protocol boundary as independently exposed: browsers, application servers, native clients, relying parties, and the network between them may each be compromised. A flow should therefore avoid giving any one participant enough material to impersonate every other participant.

These principles apply across Connect, OIDC, and native direct-issue. Some sections use Connect as the concrete example; the protocol-specific mechanics live in the corresponding integration section.

1. Redemption proof is scoped to one session

Many authentication systems use a long-lived credential — OAuth’s client_secret, an API key, or a static signing key in the application’s environment. A leak may authorize repeated operations until the credential is rotated; the exact impact depends on the protocol’s other proofs and checks.

Connect avoids using a long-lived shared secret as sufficient proof to redeem every login. Each round-trip mints a fresh hiddenKey at /establish, uses it exactly once at /redeem, and then permanently consumes it. Leaking one hidden key compromises that redemption, not every login the application has ever handled.

This applies proof-of-possession with short, narrowly scoped secrets instead of long-lived shared secrets.

Excluded alternative: using one long-lived client_secret to authenticate every token exchange.

2. Identity is separate from credentials

A Sudomimus account stores who someone is — a stable identity with a name. An authentication method stores how they prove it — a passkey, an email address, a Steam identity, an AccessKey credential. The two live in different records, and one account can hold many methods.

Consequences:

• Email ownership is not embedded in the account record. This removes one direct account-by-email data path. Enumeration resistance still depends on observable endpoint behavior, rate limits, and flow controls.
• Switching auth methods doesn’t touch identity. A user adding a passkey to their email-OTP account is just a new authentication record. The account stays the same, and so does anything tied to it.
• There is no password column anywhere. Sudomimus does not store passwords. It cannot leak passwords because it has none to leak. The supported methods are passkeys, email OTP, social sign-in (Google, GitHub, Discord, Battle.net, X), Steam, and AccessKey credentials, with more being added.

Excluded alternative: treating email as the account identity or storing password records.

3. Identity is opaque, and different for every application

Your application receives a pairwise identifier — a stable, opaque sub that is unique to your application. The same person signing into two different applications presents two unrelated identifiers, and applications use only the identifier scoped to their own sector.

Consequences:

• No cross-application correlation. Two applications cannot collude to link “their” users into one real person by comparing identifiers.
• The identifier is opaque by contract. It is an exact-match token, not a structured value to parse. Sudomimus can change its internal format without breaking you, precisely because you were never meant to read anything out of it.
• A leaked token leaks one application’s view of a user — not a platform-wide identity.

Excluded alternative: exposing one global user identifier to every relying party.

4. Users consent to what each application learns

Profile data is returned only by UserInfo, and only for claims the user has agreed to share with that specific application, plus any placeholder values the application’s policy explicitly asks for. Email, first name, last name, and avatar are each controlled independently, and a grant can be revoked at any time. UserInfo resolves policy and consent live on every call, so a revocation takes effect immediately.

Consequences:

• A requested claim may be absent. Applications must handle missing optional claims. If an application requires a claim, declare it required; Sudomimus blocks non-interactive issuance until the user consents rather than returning incomplete UserInfo.
• Bearer credentials disclose less. Access, refresh, and ID tokens contain no profile data; clients fetch current profile data from UserInfo only when needed.

Excluded alternative: releasing a user’s full profile to every application after sign-in.

5. Verification is cryptographic, not relational

When your application receives an access token, it is a signed JWT. To trust it, your application reads kid from the JOSE header and aud from the payload, selects that kid from the application’s Session JWK Set at GET /applications/{applicationAnchor}/jwks.json, and caches the set according to its response headers. Verification is local and does not require a Sudomimus request for every authenticated application request.

Consequences:

• No additional network request for each authenticated request — verification is local.
• No availability dependency between your service and Sudomimus once the user is signed in.
• Tokens are deliberately short-lived (access tokens default to a few hours, not days). When they expire, one HTTPS call to /refresh obtains a replacement without requiring the user to authenticate again.

OIDC ID tokens are a separate case: relying parties verify them against the JWKS at oidc.sudomimus.com/.well-known/jwks.json. See Tokens and verification for the full picture.

Excluded alternative: requiring a remote IdP session lookup for every authenticated request.

6. Access is allow-listed and default-deny

Who may complete an authentication, by which method, and how the result is returned are all governed by explicit allow-lists. An application with no configured rules authenticates nobody. Access remains closed until an administrator explicitly enables it.

Excluded alternative: allowing access by default until an administrator adds restrictions.

7. Failure is scoped, not amplified

A common anti-pattern is the account lockout: too many failed attempts freeze the account for a period. This can reduce brute-force attempts, but it also creates an account-level denial-of-service vector.

Each Sudomimus authentication session carries its own life counter. Failed attempts decrement that session’s life rather than locking the account. When the counter reaches zero, the session becomes invalid and the user can start a new session.

Excluded alternative: account-level lockouts triggered by failures within one authentication session.

8. Three keys, three vantage points

To forge a successful /redeem against Sudomimus, an attacker must simultaneously hold:

• A secret that lives only on the application server (the hidden key)
• A reference that was only ever sent to one specific browser (the exposure key)
• A proof that Sudomimus only mints after a real challenge succeeds (the confirmation key)

No single point of failure produces all three. A leaked URL does not compromise the server’s secret. A compromised server does not compromise other users’ sessions. A phished user does not compromise the server.

The mechanics are in the three-key model. The principle is general: split a proof three ways across three trust domains.

Excluded alternative: a monolithic session token whose compromise grants all redemption authority.

9. Trust boundaries are enforced, not documented

Sudomimus has exactly six public authentication and integration surfaces — connect-api.sudomimus.com, session-api.sudomimus.com, via.sudomimus.com, device-api.sudomimus.com, native-api.sudomimus.com, oidc.sudomimus.com. Everything an integration can reach is exposed through one of these surfaces. Product support and account-management surfaces do not grant integration authority. Other services are unreachable from outside the platform, with that boundary enforced at the platform edge.

The practical consequence: there are a small number of well-defined paths through which an authentication can be completed, and integrations cannot bypass them.

Excluded alternative: relying only on documentation or caller convention to protect an internal API.

What this means for you

An integration with Sudomimus has these properties:

• You never see a password, so you have nothing to store securely.
• You receive an opaque, per-application identifier rather than a global identifier that can be used for cross-site correlation.
• You only ever hold the identity claims a user agreed to share with you.
• Your application verifies tokens offline; Sudomimus availability doesn’t gate access to your own backend.
• A leaked per-session hiddenKey alone is bounded to its Connect session; long-lived application credentials still require careful custody and rotation.
• You don’t need to build account lockout logic.
• You still need ordinary enumeration and abuse defenses on application-owned endpoints; Sudomimus protects its own email-discovery flows at their protocol boundaries.

Next, choose an integration path or inspect the concrete Connect flow.