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 represents a person and their profile. An authentication method lets that person prove their identity with a passkey, an email OTP, a Steam identity, or an AccessKey credential. One account can use several authentication methods.

Consequences:

• Email ownership is separate from sign-in methods. Removing a sign-in method does not by itself remove verified email ownership. Enumeration resistance depends on endpoint behavior, rate limits, and flow controls.
• Adding a sign-in method preserves identity. A user can add a passkey to their email-OTP account and continue to use the same account.
• Sign-in is passwordless. Sudomimus supports passkeys, email OTP, social sign-in (Google, GitHub, Discord, Battle.net, X), Steam, and AccessKey credentials.

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 normally returned 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 and refresh tokens contain no profile data. ID Tokens also omit profile data except in the ID-Token-only OIDC response (response_type=id_token). That response includes only claims allowed by scope, current policy, and grant. Issued JWTs are snapshots; revocation cannot erase previously delivered data.

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

5. Local token verification

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. Session attempt limits

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. Key custody and redemption proof

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.

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.