Sudomimus is an OpenID Connect identity provider and an application authentication and session platform. It verifies users, controls admission to an application, and manages the identity information that the application may receive. Your application uses that identity to apply its own business permissions.
For example, a task application needs to recognize returning users, keep their sessions usable, and decide who can edit each project. Sudomimus handles authentication and its application sessions. The task application owns projects, team roles, and editing permissions. This division gives each system a clear responsibility.
Follow one user from sign-in to a project
Consider a server-rendered task application with a Sign in button:
- The application starts a login through OIDC or Connect and sends the browser to Sudomimus.
- The user authenticates with a method allowed by the application, such as a passkey or an email code. Sudomimus checks whether the user may enter that application.
- If the application requests real identity information, Sudomimus checks the user’s sharing decision. Required information must be available before sign-in can complete.
- The application handles the callback through its OIDC library or Sudomimus SDK. It validates the result and associates the external user identifier with a local user record.
- When the user opens a project, the task application’s backend checks that user’s project membership and permissions.
A successful login answers who authenticated and whether Sudomimus admitted them to the application. The project permission check answers whether that user can edit this particular project. Your backend must perform that check for each protected operation.
Divide platform and application responsibilities
| Responsibility | Sudomimus | Your application |
|---|---|---|
| Authentication | Verify the user’s proof through the configured login methods. | Start login and validate the returned result. |
| Application admission | Apply the application’s authentication, identity admission, and return rules. | Configure the rules that fit the intended audience. |
| Sessions | Issue, refresh, inspect, and revoke Sudomimus application sessions. | Protect credentials and manage any local session it creates. |
| Identity information | Evaluate current sharing policy and user consent. | Request needed fields and handle omitted or synthetic values. |
| Business permissions | Supply the authenticated identity and session context. | Own roles, resources, subscriptions, and permission checks. |
A Sudomimus application access token is a credential for its intended application’s session. It does not grant permission to edit a project, read an invoice, or call an unrelated API. Those decisions remain in your application.
Choose OIDC or Connect for web sign-in
Use OpenID Connect when your application already supports an OIDC provider or needs a standard OIDC integration. Your OIDC library handles the protocol. A relying party can validate the ID Token and establish its own local session.
Use Connect when you want the Sudomimus integration flow and an official framework SDK fits your application. The SDK can handle the signed start request, callback redemption, and application-session operations on your server.
Both paths use the hosted authentication experience. Your application does not collect the user’s passkey or email code. OIDC and Connect are alternative integration paths; you do not need to implement Connect before using OIDC.
The OIDC and Connect comparison explains the setup choices. For a CLI or native application, start with the integration selection guide, which also covers Device and Native flows.
Treat sign-in and session lifetime separately
The callback establishes an authenticated result. The application must also handle expiry, refresh, and logout during later use.
Checking a JWT’s signature, audience, and expiry establishes the validity of the issued credential under those checks. It does not query the current state of the Sudomimus session. When an operation requires current Sudomimus session authority, your backend can use Session introspection. See tokens and verification.
If your application creates a separate local session, it owns that session’s lifetime. Configure how local sessions respond to logout and changes in Sudomimus authority. A locally valid cookie does not automatically become invalid when the upstream session ends.
Request identity information deliberately
The task application may need a user identifier without needing a real email address. Sudomimus exposes a sector-scoped subject as sub; the internal account UUID stays inside the platform. Related applications can deliberately share a sector, while applications in different sectors receive different subjects for the same account.
Email, names, and account avatars have separate sharing controls. The developer configures a per-application policy, and the user decides whether to grant access to real information. OIDC additionally requires the corresponding scope. An optional field may be absent, and a synthetic policy may return a placeholder instead of real information.
For the authorization-code flow, Sudomimus puts profile information in UserInfo rather than the ID Token returned by the code exchange. A successful login therefore does not promise an email field in the ID Token or access to the user’s real mailbox address.
Read OIDC user identifiers, email, and privacy for the identifier design. If your integration already works but email is missing, use the email-claim troubleshooting guide.
Start with one application and one complete flow
Use the With portal to create and configure an application in your organization. Choose its login methods, admission rules, exact callback destinations, and identity-sharing policy before activating it.
Then follow the guide for your integration:
- OIDC authorization-code integration for an application with an OIDC library.
- Next.js App Router sign-in for a Next.js application using Connect.
- React Router Framework Mode sign-in for a React Router application using Connect.
Test a returning user, denied admission, expired credentials, logout, and an optional profile field that is not shared. In the task application, also verify that a signed-in user cannot edit a project without the required project permission.