Skip to content
Sudomimus

Organizations and applications

View as Markdown

Organizations own applications and sectors. If you are building with Sudomimus for a team, create or join an organization first, then manage applications inside it.

Create an organization

Section titled “Create an organization”

In with.sudomimus.com, open the developer area and create an organization. The creator becomes the first owner.

Keep at least two active owners for production organizations. Some retirement and deletion operations protect the last owner, so do not use a throwaway personal account as the only owner of important resources.

Invite members

Section titled “Invite members”

Members are invited by account alias. The user can find their alias in their account area.

RoleUse it for
ViewerRead-only inspection of applications, sectors, domains, and rules.
AdminDay-to-day configuration: applications, rules, keys, domains, and connectors.
OwnerMembership, role changes, and retirement operations.

Use the lowest role that lets someone do their job.

Register an application

Section titled “Register an application”

Create an application inside an organization when you are ready to integrate a product, service, game, or tool.

After creation, record:

  • applicationAnchor - the public client identifier used by Connect, OIDC, Device, Native, and SDK setup.
  • Client-auth private key - shown when you create the application and used by confidential backends to sign /establish, Session /revoke-all, and OIDC private_key_jwt.
  • OIDC client secret - needed only when your OIDC return rule uses client_secret_basic or client_secret_post. Generate or rotate it from the application page.

Store private keys and client secrets as production secrets. If a key or secret leaks, rotate it from the application page and update your backend.

Application creation and client-auth rotation results also show the matching public key. You can copy it as original PEM or DER Base64; unlike the private half, it is not secret.

If creation or rotation ends with an unknown network result, retry the unchanged form. The portal preserves the operation identifier and can recover the exact committed result for ten minutes. A committed rotation still invalidates the old key immediately; recovery does not create an overlap window.

Manage token-signing keys

Section titled “Manage token-signing keys”

Open the application’s Signing Keys tab to inspect the complete signing-key lifecycle and copy the canonical Session JWKS URL. Viewers can inspect and copy each key as original PEM, DER Base64, or JWK with Base64URL members, and download public PEM and JWK files. Admins and owners can:

  • Prepublish one replacement key so cached verifiers can discover its kid.
  • Activate it after the displayed cache-warm boundary. The previous key enters RETIRING and remains published for the maximum token lifetime.
  • Cancel a pending key, or emergency-revoke a retiring key when accepting its outstanding tokens is a greater risk than breaking them.

Emergency revocation removes the key from fresh Session JWKS responses immediately. Verifiers that already cached it may continue accepting its signatures for the remainder of their advertised cache lifetime, up to 300 seconds after their last successful fetch. Treat that bounded convergence window as part of incident response.

Token consumers should cache the Session JWKS and select the exact key named by the JWT kid. The application creation result and Credentials tab do not expose a singular token-signing public key.

Configure claims

Section titled “Configure claims”

On the application page, configure claim policy for email, first name, last name, static avatar, and animated avatar.

Ask only for claims your product actually needs. If a claim is optional, design your UI to work when the user denies it. If a claim is required, be ready to handle consent or missing-data recovery.

Configure rules

Section titled “Configure rules”

Every application needs all three rule layers:

  • Layer 1 - which sign-in methods are allowed.
  • Layer 2 - which identities may log in.
  • Layer 3 - how the result is delivered.

The common setup for a web application is passkey or email OTP, an EVERYONE or email-based realize rule, and a CALLBACK return rule.

Sectors and pairwise identity

Section titled “Sectors and pairwise identity”

A sector groups applications that should see the same pairwise subject for a user. Use one sector when products intentionally share an account identity. Use separate sectors when products should not be able to correlate users through Sudomimus identifiers.

Retire resources

Section titled “Retire resources”

Applications and sectors are disabled rather than deleted. Disable an application before decommissioning it, and make sure clients stop using its keys and tokens.

Account deletion can be blocked when you are the sole owner of an organization with live applications or sectors. Retire the resources or add another active owner before deleting the account.

Section titled “Related”