Single Sign-On for empowsec: SAML, OIDC, and OAuth Explained

Asking employees to maintain a separate username and password for every SaaS tool their organization uses is a security problem dressed up as an access management problem. Separate credentials mean more passwords to create, more passwords to forget, more password resets to handle, and more opportunities for weak or reused passwords to create a security gap. Single sign-on solves this by making your identity provider the single source of authentication truth: employees sign in once, to the system they already trust, and that credential is used to access all connected applications. empowsec supports SSO via three widely deployed protocols - SAML 2.0, OIDC, and OAuth - making it compatible with the identity providers most enterprises already run.

This article explains how SSO works in empowsec, what each protocol option covers, how per-domain configuration and attribute mapping work, how users are auto-provisioned on first login, and how cross-domain authentication supports white-label deployments.

Why SSO Matters for a Security Awareness Platform

There is a certain irony in a security awareness training platform that asks employees to create yet another password. Every additional credential is a potential weak link: if an employee chooses a weak password for their empowsec account, or reuses a password they use elsewhere, the account is at risk even if empowsec itself is perfectly secure. SSO eliminates this problem at the root by replacing the empowsec-specific password with the credential the employee already manages through your identity provider - which is typically subject to your organization's password policy, multi-factor authentication requirements, and account lifecycle management.

For IT teams, SSO also simplifies access management considerably. When an employee leaves the organization and their identity provider account is deactivated, their empowsec access is revoked as a consequence. There is no separate offboarding step in empowsec, no risk of a former employee retaining access because someone forgot to remove them from the training platform. The identity provider is the authoritative control plane, and empowsec respects it.

From a compliance perspective, centralized access management through SSO supports the access control requirements found in standards like ISO 27001 and frameworks like NIS2. Having all access to internal systems - including the security awareness training platform - flow through a single, auditable identity provider makes it straightforward to demonstrate that access is controlled, monitored, and tied to the employee lifecycle.

Protocol Support: SAML 2.0, OIDC, and OAuth

empowsec supports three SSO protocols, giving organizations flexibility to connect whichever identity provider they already use.

SAML 2.0 (Security Assertion Markup Language) is the most established enterprise SSO standard and is the native protocol for many corporate identity providers, including Microsoft Active Directory Federation Services and many legacy enterprise directories. SAML works by having the identity provider issue a signed XML assertion that vouches for the user's identity, which empowsec validates before granting access. For organizations whose identity provider speaks SAML, this is the most direct integration path.

OIDC (OpenID Connect) is the modern identity layer built on top of OAuth 2.0. It is the preferred protocol for cloud-native identity providers including Google Workspace, Microsoft Entra ID (formerly Azure AD), and Okta. OIDC exchanges identity tokens rather than XML assertions, which is generally simpler to configure and more suited to API-first architectures. Organizations that have moved to cloud identity providers are likely to prefer OIDC.

OAuth support rounds out the options for organizations using OAuth-based identity flows that do not wrap a full OIDC layer. Together, the three protocol options mean that regardless of whether your identity provider is a traditional enterprise directory, a cloud identity service, or something more bespoke, empowsec can integrate with it.

Per-Domain Configuration and Attribute Mapping

SSO in empowsec is configured per domain. This means that the SSO integration is associated with a specific email domain - for example, acme.com - and applies to all users who sign in with that domain. When a user with an acme.com email address attempts to sign in to empowsec, the platform detects that SSO is configured for that domain and redirects them to the appropriate identity provider. Users with other domains use their own configuration or standard password authentication.

Per-domain configuration is particularly valuable for multi-company or reseller deployments, where different companies on the platform may have different identity providers and SSO configurations. Each company configures SSO for its own domain independently, and empowsec routes sign-in requests to the correct identity provider based on the email domain.

Attribute mapping is the mechanism by which the identity provider's user data is translated into empowsec user attributes. When an identity provider authenticates a user and returns a token or assertion, it includes a set of attributes: typically the user's name, email address, and any custom attributes the organization has configured. Attribute mapping tells empowsec which identity provider attribute corresponds to which empowsec field - so, for example, the identity provider's 'department' attribute maps to the empowsec department field, and the 'displayName' attribute maps to the user's full name in empowsec. Getting this mapping right is what makes auto-provisioning work cleanly.

Auto-Provisioning on First Login

One of the most operationally valuable aspects of SSO in empowsec is auto-provisioning. When a user signs in via SSO for the first time, empowsec automatically creates their account using the attributes from the identity provider. The user does not need to be pre-created in empowsec, and no manual import step is needed before they can access the platform.

Auto-provisioning via SSO works well alongside the CSV import and API provisioning options described in the user management article. For organizations that prefer to provision users in advance, CSV import or the API is the right approach. For organizations that prefer to let the SSO flow handle provisioning, first-login auto-provisioning means the employee simply signs in and their account exists. In practice, many organizations use a hybrid approach: bulk-import the existing workforce on day one of the empowsec rollout, then let SSO auto-provisioning handle new joiners going forward.

The quality of auto-provisioning depends on the attribute mapping configuration. If the identity provider is configured to include the employee's department, manager, and any other relevant attributes in the SSO token, empowsec can populate all of those fields at provisioning time. The employee's account is created in the right department, with the right role, ready to receive their first training assignment without any manual intervention. If the identity provider only provides basic attributes like name and email, the provisioned account will be created with defaults that an administrator can refine afterward.

Cross-Domain Authentication for White-Label Deployments

empowsec's SSO support extends to cross-domain authentication, which is what makes SSO work for white-label deployments. When a reseller serves empowsec to their clients under a custom domain - for example, portal.theirbranding.com - the authentication flow needs to work across the boundary between the client's custom domain and the underlying empowsec infrastructure. Cross-domain authentication handles this transparently: the user signs in on the custom domain via their identity provider, and the authentication is correctly propagated across the domain boundary to empowsec.

This capability is important for the white-label use case because SSO is often a non-negotiable requirement for enterprise clients. If an organization is deploying a security awareness training platform under a custom domain for their enterprise clients, those clients will expect to be able to sign in via their existing identity provider rather than maintaining separate credentials for the training platform. Cross-domain authentication via SSO makes this possible and keeps the custom-domain experience seamless.

SSO and Security: Reducing Password Risk in Practice

The security benefits of SSO for empowsec are straightforward: employees do not create a separate password for the platform, so there is no empowsec-specific password to be weak, reused, or compromised. Access is governed by the organization's identity provider, which is typically subject to stronger password policies and MFA requirements than employees would apply to a third-party SaaS tool they consider less important.

SSO also makes it easier to enforce multi-factor authentication consistently. If MFA is required at the identity provider level, every application that uses SSO - including empowsec - inherits that MFA requirement. This is significantly more reliable than trying to enforce MFA across dozens of individual SaaS applications separately. For organizations working toward a strong access control posture as part of a compliance program, SSO is one of the most effective levers available for ensuring consistent authentication standards across the tool stack.

For empowsec in particular, the irony reduction is also worth noting: an organization that uses empowsec to train employees about password security and phishing risks should not be asking those same employees to maintain weak standalone credentials for the platform itself. SSO aligns the access model with the security values the training is trying to instill.

What This Means for Your Team

• SAML 2.0, OIDC, and OAuth support means empowsec integrates with the identity provider your organization already uses, whether that is a traditional enterprise directory or a cloud-native identity service.
• Per-domain configuration allows different SSO setups for different email domains, which is essential for multi-company and white-label deployments.
• Attribute mapping translates your identity provider's user data into empowsec fields at provisioning time, populating department, name, and other attributes without manual setup.
• Auto-provisioning on first SSO login creates user accounts automatically when employees sign in for the first time, eliminating the need for a separate pre-provisioning step.
• Cross-domain authentication makes SSO work seamlessly for white-label deployments on custom domains, meeting enterprise clients' expectation of using their existing identity provider.
• Reduced password risk by removing the need for a separate empowsec credential, with consistent MFA enforcement inherited from the identity provider.