Sign in
← Articles and guides

Choose OIDC or Connect for application sign-in

Compare Sudomimus OIDC and Connect, then configure the path that fits your application.

Sudomimus offers two paths for web application sign-in. Both send the user to the hosted authentication page. Your application does not collect the user’s passkey or email code. The difference is the protocol your application uses before and after that visit.

Start with your application’s integration surface

Your application Choose Why
It already supports an OpenID Connect provider OIDC Use its existing OIDC library and standard authorization code flow.
It is a new web application using an official Sudomimus framework SDK Connect The SDK handles the signed start request, callback, and application session.
It needs an ID token or standard OIDC scopes OIDC These are part of the OIDC contract.
It needs a custom Sudomimus login flow without an OIDC library Connect The application controls the Connect inquiry and return method.

These are alternative integration paths. Connect is not a setup step for OIDC.

See the OIDC product page and application sign-in page for the user-facing experience of each path.

Set up OIDC

  1. In the With portal, create an application. Add an OIDC return rule with the exact redirect URI and allowed scopes. Configure the authentication and realize rules that admit your users. Activate the application when the configuration is ready.
  2. Set your OIDC library’s issuer to https://oidc.sudomimus.com. Read the discovery document for the current endpoints and advertised capabilities.
  3. Set the application’s applicationAnchor as the OIDC client_id. Choose the client authentication method configured in the return rule. Use authorization code with PKCE (S256), and validate state, nonce, issuer, and tokens through your OIDC library.

For the rule shape, client authentication options, and callback checks, follow the OIDC integration guide.

Set up Connect

  1. In the With portal, create an application and configure its authentication, realize, and callback return rules. The callback URL must match the return rule. Activate the application before login.
  2. Keep the application client-auth signing key on your server. Use an official framework SDK when one fits your stack. The SDK starts a signed /establish inquiry, sends the browser to Sudomimus, and redeems the result on your callback route.
  3. Keep the resulting application session on the server. Do not send access or refresh tokens to a browser component. Use the Session API or the SDK’s session helpers for refresh and logout.

For a working route layout, see the Next.js App Router guide or the complete Connect tutorial.

Before you launch

Test a successful login, a denied or expired login, a callback URL mismatch, and logout. Check which claims your application requests and which claims the user has allowed Sudomimus to share. Applications receive a purpose-scoped subject, not the underlying account ID.

If you are building a CLI or native client rather than a web application, compare all four integration paths before choosing either of these web flows.