Use your customer’s identity provider for sign-in
Connect an organization’s identity provider through OpenID Connect. Members use the customer’s sign-in process, while Wildo connects the verified identity to the application’s account and membership rules.
Each connection belongs to its configured scope. Domain verification and connection policy determine when it is offered and how people are provisioned.
Example — Sign in through the company directory
A member enters their company address, follows the organization’s configured identity provider and returns to the application’s workspace with the permitted membership.
For engineers
Establish the connection and routing authority
The user type must enable AuthMethod.ORG_OPENID_CONNECT. The organization also needs an enabled SSO connection, client configuration and verified domain routing. Claiming a domain is not verification; DNS verification grants the routing authority. The application-scope connection has its own authorize path.
Connect the method, tenant and identity provider
Example: permit OIDC for a user type whose other authentication policy already exists. Merge into userTypes.<type>.auth in backend-api/src/saas-config.backend.ts. Import AuthMethod from @wildo-ai/saas-models.
const customerAuth = {
...existingCustomerAuth,
authMethodsEnabled: {
...existingCustomerAuth.authMethodsEnabled,
[AuthMethod.ORG_OPENID_CONNECT]: true,
},
};
This permits the method; it does not create an IdP connection, verify a domain or grant membership. The initiating frontend must admit the same user type. Organization method policy can further restrict or expand available methods within the application’s declared rules.
| Setup owner | What must agree |
|---|---|
| Application auth policy | OIDC is permitted for the intended user type and frontend |
| Scoped SSO connection | An enabled connection belongs to the application or customer organization being authenticated |
| Identity-provider application | Client credentials and the callback registered for this deployment match |
| Domain routing | Organization discovery uses verified domain ownership, not an unverified domain claim |
| Provisioning policy | The verified subject maps to the intended local account and permitted membership |
Use the standard scoped connection configuration service for manual metadata, provider templates or discovery. Those modes supply issuer, endpoints and keys; they are not three different trust policies. Keep client secrets in the backend configuration/secret path and register the callback supplied for the selected scope and deployment.
Verify the returned identity
Wildo validates the ID-token signature, expected issuer, client audience, expiry and issuance time before trusting its claims. It binds the nonce to the request and the identity to the returned profile. Missing verification metadata refuses ID-token processing; an unverified decode is not a fallback.
If the connection declares acrValues, the verified token must contain an accepted acr. Requesting a value does not prove it was returned, and a generic amr list does not substitute for the requested authentication context. Delegated enterprise MFA does not bypass this explicit demand.
Connect authentication to provisioning
The enterprise provisioning service resolves the external subject, local account, profile and membership. Just-in-time creation follows configured provisioning rules; directory provisioning is a separate lifecycle channel for joiners and leavers. Enterprise OIDC accepts delegated MFA assurance from the configured customer identity provider; it does not claim Wildo observed individual factors. The customer owns the IdP’s authentication policy, while Wildo retains token validation, identity binding and local access checks. Callback completion uses its own admission path and does not enter the native second-factor continuation.
Keep local access policy deliberate
Enforced SSO, migration grace and named emergency accounts are policy choices on the scope’s configuration. Active directory management disables local first-factor paths that would bypass the customer’s directory. These decisions belong beside connection setup, not in a custom callback that silently falls back to a local password.
This capability makes Wildo a client of the customer’s identity provider. Wildo’s own OAuth authorization-server and delegated-agent access surfaces answer a different question.