Single sign-on (OIDC)
OIDC lets employees sign in to LadVen OS through the company identity provider. It changes portal sign-in; it is not a CRM data channel.
Before you configure it
Check whether Single sign-on (OIDC) is available in CRM → Integrations. Some deployments enable the connector only with the portal provider. The wizard fields are deployment-specific, so do not copy values between environments.
Prepare the provider issuer, allowed redirect URIs, client name, and required claims/scopes. Use a separate service client with minimum access.
Configure the connector
- In CRM → Integrations, add Single sign-on (OIDC) if it appears in the catalog.
- Fill in the fields shown by the wizard, save a draft, and test the connection.
- A client secret may be shown once. Copy it immediately to a secrets manager. After the window closes, only a safe representation remains; issue a new secret if it is lost.
- Enable sign-in only after checking redirect URIs, a test account, and an administrator recovery path.
Never put real secrets, corporate identifiers, or user addresses in screenshots, tickets, or examples.
Employee sign-in
The employee opens the corporate sign-in link. LadVen OS may show the application and requested scopes (identity, profile, email, or long-lived access). Check the application name and scopes, then choose Continue/Allow access or Deny.
The consent link is single-use and expires. If the interaction is missing or expired, start sign-in again and do not share the link.
Temporary interaction screen
After the identity provider redirects back, the portal may open the temporary /oidc/interaction/:uid route. It is the consent check for one sign-in, not a settings page: uid is single-use and expires quickly. Do not bookmark, ticket, or screenshot this address. If the interaction expires, return to the corporate sign-in link and start again.
The screen shows the client name and, when supplied safely, links to its website, policy, and terms. Review both requested and still-missing scopes (requestedScopes and missingScopes); missing claims are listed separately. For example, openid confirms identity, profile requests a profile, email requests an address, and offline_access requests long-lived refresh-token access. Do not approve an unexpected permission.
Distinguish prompt=login from consent: login continues the current staff sign-in, while consent asks you to grant the application access. Choose Allow access/Continue only after reviewing the client and scopes; Deny ends this request without granting access. An empty or already-granted scope list means basic identity confirmation, not new privileges.
The page can first show a loading state. If the uid is missing, unknown, or expired, it shows an error and Retry button; retrying does not extend the interaction. Return to the original corporate link and start sign-in again.
Troubleshooting
- Connector missing: ask the portal owner or provider; availability can be deployment-specific.
- Connection check fails: verify issuer, redirect URI, server time, and provider claims.
- Secret lost: revoke the old client and issue a new one; never send it in chat.
- Expired interaction: retry from a new corporate sign-in link.
Related pages