SSO and MFA in Hexnode IdP: Setting Up Centralized Authentication

Why fragmented authentication creates an access-control problem

Managing separate credentials, sign-in processes, and access assignments across enterprise applications fragments access control. IAM and IT administrators must maintain multiple consoles, reconcile inconsistent user records, and determine which system governs each entitlement.

This fragmentation slows onboarding because every application requires individual setup. It also complicates offboarding, periodic access reviews, and consistent authentication-policy enforcement, increasing the risk that stale or mismatched access remains unnoticed.

Centralized single sign-on (SSO) consolidates authentication into a consistent workflow, reducing repeated credential prompts. Pairing SSO with multi-factor authentication (MFA) adds another identity-verification step before users access assigned applications.

What happens when SSO and MFA remain disconnected?

When SSO and MFA remain disconnected, organizations may simplify access without consistently strengthening identity verification. Password reuse, uneven authentication controls, excessive application access, and delayed revocation increase exposure when credentials are compromised or users change roles.

Fragmented workflows also generate more support tickets and manual administrative work. Employees wait longer for access, while IAM teams struggle to produce clear audit evidence showing who can access each application and how users authenticate.

SSO improves convenience, but it is not a complete security control. It should operate alongside MFA, carefully scoped application assignments, and lifecycle controls that provision, review, and revoke access appropriately.

How do SSO and MFA work together in Hexnode IdP?

Hexnode IdP supports SAML 2.0 and OIDC single sign-on for configured applications and provides multi-factor authentication using authenticator-app or email verification methods, according to the applicable sign-in configuration.

Hexnode IdP acts as the identity provider for configured SAML 2.0 and OIDC applications, authenticating users through its supported identity and authentication workflows before allowing the application to establish a session. The service provider in SAML, or client application in OIDC, redirects the user to Hexnode IdP instead of handling the central sign-in itself. After validating the primary credentials and MFA challenge, Hexnode IdP returns a SAML assertion or OIDC token that the application uses to establish a session.

These controls serve different purposes. SSO performs authentication by confirming identity, while application assignments determine which users or groups are authorized to access a resource. Provisioning is separate: when configured for a supported application, SCIM 2.0 can manage operations such as creating, updating, or deactivating downstream accounts. A successful sign-in therefore does not represent complete access governance.

Which Hexnode IdP features support centralized authentication?

Hexnode IdP supports centralized authentication through MyApps, application Assignments, and App Groups. Together, these features configure application connections and define which directory identities may use them.

• Applications > MyApps: Administrators add and manage SAML 2.0 and OIDC integrations here. Each integration contains protocol-specific SSO settings, such as service provider identifiers and endpoints for SAML or redirect URIs, client types, scopes, and grant types for OIDC.
• Assignments: Each configured application includes an Assignments section where administrators can Include or Exclude individual users and groups. Include grants application access, while Exclude explicitly denies it. If an identity matches both rules, Exclude takes precedence over Include.
• App Groups: Administrators can bundle already configured SAML 2.0 and OIDC applications by department, role, or business function. Assignments applied to an App Group control access across its related applications, reducing the need to repeat the same access configuration for each integration.

Feature Resource

Hexnode IdP use cases

Check out this document for a quick glance into Hexnode IdP's capabilities.

Get the Infographic

What should administrators prepare before setup?

Before starting, confirm the identities, permissions, application parameters, and recovery paths required for a controlled deployment.

• Administrative access: Verify administrator access to Hexnode IdP and the target application.
• User readiness: Confirm that active identities exist and select a limited group of pilot users.
• Integration documentation: Obtain the target application’s official SSO requirements. Gather the SAML ACS URL and Entity ID, or the OIDC redirect URIs, application type, and client type.
• MFA readiness: Ensure pilot users can access their corporate inboxes and have a compatible authenticator application when required.
• Recovery planning: Define rollback steps and maintain a tested break-glass method for restoring administrative access if authentication fails.

Step 1: Add the application and choose SAML 2.0 or OIDC

With the prerequisites confirmed, sign in to the Hexnode IdP portal and navigate to Applications > MyApps > + Add Apps. Select SAML 2.0 or OIDC, rename the untitled application, and optionally upload its logo for easier identification. Save the application details before continuing to the SSO configuration.

Choose the protocol according to the target application’s supported integration and architecture:

• SAML 2.0 generally suits established enterprise web applications that exchange XML-based authentication assertions between an identity provider and service provider.
• OIDC generally suits modern web applications, native mobile or desktop applications, and single-page applications that use token-based authentication.

Do not select a protocol based only on application age or type. Consult the target application’s official integration documentation to confirm its supported protocol and required values. Endpoint URLs, identifiers, client settings, and other parameters must match the application’s requirements rather than values inferred from a similar integration.

Step 2: Configure the application’s SSO connection

For SAML 2.0, enter the ACS URL, Entity ID, Audience URI, Name ID Format, and Logout URL supplied by the service provider. Match every value exactly, including the scheme, capitalization, path, and trailing slash where applicable. An incorrect ACS URL or Entity ID can prevent the service provider from accepting the SAML response.

For OIDC, select the Application Type that matches the application architecture, then choose a Public or Confidential Client Type. Public clients cannot securely store a client secret, so Hexnode IdP requires PKCE for them. Configure the approved login redirect URIs and logout URIs, then select only the allowed scopes and grant types required by the client. Available settings include OpenID, profile, email, offline access, Authorization Code, and Refresh Token.

After completing the remaining provisioning and assignment pages, inspect the configuration on the Review page and select Create. Test a valid assigned-user sign-in, then confirm that invalid endpoints and unassigned accounts fail as expected. These negative tests verify that the integration rejects requests outside its configured trust and access boundaries.

Step 3: Assign authorized users or groups, or use App Groups

Open the configured application under Applications > MyApps, then select its Assignments section. Use All, Users, or Groups to locate the identities that should receive or be denied access.

Add authorized identities under Include to grant application access. Place exceptions under Exclude to deny access. If a user matches both rules, Exclude overrides Include, including when the user belongs to an included group.

Start with a controlled pilot group and verify that each assignment follows least-privilege requirements. Expand access only after assigned users can complete the intended sign-in flow and excluded users are denied. For related applications, use an App Group to apply assignments across the bundle.

Step 4: Complete MFA enrollment for Hexnode IdP users

After administrators configure application access, each user completes MFA enrollment through the initial Hexnode IdP account flow. The user opens the activation email and either creates a password or signs in with the password provided by the administrator. Hexnode IdP then displays the MFA setup screen.

For Authenticator App verification, the user scans the displayed QR code or manually enters the 32-character key. The authenticator application generates a six-digit code, which the user enters on the setup screen. Alternatively, Email Verification sends a code to the user’s corporate email address for confirmation.

Users who want both Authenticator App and Email Verification available must configure both during this initial setup flow before selecting Save. This is a user enrollment process and is separate from the administrator’s SAML or OIDC application configuration in MyApps.

Step 5: Test authentication, recovery, and operational visibility

Before wider deployment, test assigned and excluded accounts, each supported SSO entry point, MFA challenges, and logout behavior. Include representative SAML, OIDC, web, native, or single-page applications used in the planned rollout.

Validate recovery during the pilot. Users may add a recovery email during initial account setup. If a user loses access without configuring one, the user must contact an administrator to reset the enrolled MFA factors.

Monitor the Users Dashboard for MFA Adoption Rate and sign-in activity. Review the Applications Dashboard for SSO configuration status, protocol distribution, login errors, application usage, and assignment insights. Use these indicators to identify enrollment, configuration, or adoption gaps.

How Hexnode IdP brings SSO, MFA, and app access into one workflow

Hexnode IdP centralizes authentication by configuring supported SAML 2.0 and OIDC application connections under MyApps. Compatibility depends on each target application’s protocol support and integration requirements.

For access control, Include and Exclude Assignments determine which users and groups can access an individual application, with Exclude taking precedence. App Groups extend this assignment model across bundles of configured applications.

Users strengthen sign-in verification by enrolling an Authenticator App, Email Verification, or both during initial account setup. Administrators can track MFA adoption through the Users Dashboard’s MFA Adoption Rate widget and review authentication activity through Login Activity and Last 10 Sign ins. The Applications Dashboard provides visibility into SSO configuration, application usage, assignments, and integration health.

FAQs

Start a controlled Hexnode IdP authentication rollout

Begin with one business-critical application and a limited pilot group. Evaluate how Hexnode IdP centralizes SSO, supports MFA-backed sign-ins, applies application assignments, and surfaces authentication activity before expanding deployment. Request a demo or start a trial to validate the workflow against your organization’s identity architecture and access requirements.