---
title: Organizations and applications
description: Configure organizations, members, applications, sectors, keys,
  claim policy, and rules in the With portal.
editUrl: true
head: []
template: doc
sidebar:
  order: 5
  hidden: false
  attrs: {}
pagefind: true
draft: false
---

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

In [`with.sudomimus.com`](https://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

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

| Role | Use it for |
|---|---|
| Viewer | Read-only inspection of applications, sectors, domains, and rules. |
| Admin | Day-to-day configuration: applications, rules, keys, domains, and connectors. |
| Owner | Membership, role changes, and retirement operations. |

Use the lowest role that lets someone do their job.

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

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

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

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

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

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.

## Related

- [Configuration templates](/en-us/application-rules/templates/) - starting points for common application types.
- [Layer 3 — Return rules](/en-us/application-rules/return-rules/) - callbacks, polling, device code, direct-issue, and OIDC.
- [Account deletion](/en-us/guides/account-deletion/) - how organization ownership can block erasure.