Single sign-on (OIDC)

Business plan and above

NexoVirt supports OpenID Connect (OIDC) single sign-on for admin logins. Any standard OIDC provider works (Keycloak, Authentik, Microsoft Entra ID, Google Workspace and others). With team roles (RBAC) on your license, IdP groups also decide each admin’s panel role.

Settings → Single sign-on

Field	What it is
Enable OIDC login	Turns the Sign in with SSO button on the login page on or off.
Issuer URL	Your provider’s issuer, for example https://idp.example.com. Endpoints are discovered from /.well-known/openid-configuration.
Client ID / Client secret	The credentials of the application you register at the IdP. The secret is stored encrypted and never shown again; leave the field blank to keep the stored one.
Scopes	Comma-separated. Default openid, profile, email, groups.
Redirect URI	Read-only: the callback URL to register at your IdP (https://panel.example.com/login/sso/callback).
Provisioning mode	Link only (existing users) (default) or Just-in-time (gated by domain/group).
Allowed domains	Comma-separated email domains. Only used for just-in-time provisioning.
Group claim	The token claim that carries the user’s groups, for example groups.
Required group	Optional. Just-in-time accounts are only created for members of this group.
Role map	One idp-group=role per line, used for the role of just-in-time accounts.
Enforce SSO (disable password login for admins)	Hides the password form on the login page. Only possible after at least one verified SSO login, so you cannot lock yourself out.

1. Register an OIDC application at your identity provider and use the Redirect URI shown on the settings page as its callback.
2. Fill in Issuer URL, Client ID and Client secret, tick Enable OIDC login and choose Save single sign-on.
3. Log out and choose Sign in with SSO on the login page. After a successful login the settings page shows when SSO was last verified.
4. Optionally turn on Enforce SSO once you have verified the login.

How accounts are matched

On each SSO login NexoVirt looks for the account in this order:

1. An active account already linked to the IdP user (the sub claim).
2. An active account with the same email address, if the IdP marks the email as verified. The account is then linked.
3. In Just-in-time mode only: a new account, if the email domain is in Allowed domains and the user is in Required group (when set). The username is taken from the email address.

Anything else is refused with “No panel access for this account.”

Team roles from IdP groups

With team roles (RBAC) on your license, the RBAC role mapping section maps IdP groups to the panel roles super-admin, operator and read-only:

• Group → role mapping: one idp-group=role per line, for example idp-admins=super-admin. The first matching group wins.
• Default role for unmapped users: the role for everyone else (default super-admin).

The role is re-evaluated on every SSO login, so changing a user’s groups at the IdP takes effect at their next login.

Admin logins only, and audited

SSO is for admins: customers and resellers log in with their password and 2FA as usual, and a non-admin SSO login is refused with “SSO is limited to administrators.” SSO logins skip the panel’s own 2FA challenge, so enforce MFA at your IdP. Every SSO login, refusal and role mapping is written to the audit log (sso.login, sso.denied, sso.role_mapped).

Keep a local way in

Before you enforce SSO, make sure you can reach the server: if the IdP is unreachable while enforcement is on, admins cannot log in with a password.