SSO: How Single Sign-On Works and How It Is Implemented in MULTIFACTOR

In a corporate infrastructure, there are almost always more entry points than desired. Email, VPN, internal portals, development systems, cloud services — each resource has its own authentication mechanism, its own password requirements, and, consequently, its own risk area.

Over time, this leads to typical problems: users start reusing passwords, writing them down in notes, sticking password stickers on their monitors, or simply forgetting them. IT support spends time on resets, and the information security department gets additional points of potential compromise.

Against this backdrop, Single Sign-On (SSO) technology has evolved from a convenient option into a fundamental element of modern access infrastructure. It allows centralized authentication and removes redundant checks without reducing (and, when properly implemented, increasing) the level of security.

Let's look at how SSO is structured at the protocol and architecture level, and how this technology is implemented in the MULTIFACTOR system for multi-factor authentication and access control.

What SSO is and how it works

Single Sign-On is a mechanism in which a user authenticates once and gains access to all connected systems without re-entering credentials.

System components using MULTIFACTOR as an example

IdP (Identity Provider) — the SSO solution itself, which includes the logic for authentication, management of master and client sessions, and auditing.

DBs (main/history) — IdP storage (main — operational data (active sessions), history — audit (logs, all sessions)).

External Identity Server — the source of user credentials (LDAP, AD, Azure AD, OIDC, etc.).

SSP (Self Service Portal) — the interactive IdP portal where the user can manage their sessions, MFA, and profile. Essentially, the IdP UI.

SP (Service Provider) — the application/service that requires login (for example, a CRM). It delegates authentication to the IdP and receives tokens/assertions from it.

The key point here is the separation of roles. Authentication is moved to a separate component — the Identity Provider (IdP), and the applications themselves become consumers of this authentication — the Service Provider (SP). Applications no longer check the user's password themselves; they trust the result of the check performed by the IdP.

From a technical perspective, the process looks like a chain of redirects and token exchanges.

When a user opens an application (for example, a corporate portal), it does not authenticate them directly but redirects them to the IdP. There, the user enters their login and password (and in MULTIFACTOR—also completes the second factor). After successful verification, the IdP creates an assertion that the user is authenticated and sends it back to the application. This assertion can be implemented as a SAML Assertion or a token (for example, a JWT in the case of OIDC).

The application verifies the signature and validity of this assertion and, if it trusts the IdP, grants access without requesting a password. Subsequently, the user can access other applications, which will use the existing IdP session—no re-authentication is required.

Protocols and technical implementation

SSO is not a single protocol but a set of standards that solve the same problem in different ways.

In corporate environments, SAML 2.0 is most commonly used. It is an XML-oriented protocol in which the IdP creates an Assertion—a document containing user information, signed with a digital signature. The application (SP) receives this document through the user’s browser and validates it.

In more modern scenarios (especially for web and mobile applications), the OAuth 2.0 and OpenID Connect combination is used. Here, JSON is used instead of XML, and user identity verification is transmitted via an ID Token. Unlike SAML, OIDC is easier to integrate into SPAs (single-page applications) and mobile applications.

Kerberos addresses the same problem but at a completely different level—the network level. It works like this: the user enters a password once and receives a special ticket—the Ticket Granting Ticket (TGT). It acts like an entry pass. Then, when the user wants to access a service, Kerberos issues a service ticket based on the TGT. The password is not requested again. This is the classic SSO mechanism within Active Directory.

LDAP in this scheme is usually not an SSO protocol but is used as a source of user data—this is where the IdP gets information about accounts.

SSO usage scenarios

Let’s look at two typical scenarios: when the user does not yet have a session in the Identity Provider and when one already exists.

Scenario 1: SP-initiated login without a master session

Context: the user is in the application (SP) and clicks "Log In". They do not have an active master session in IdP (SSP).

Sequence of actions:

1. The application (SP) initiates the authentication process by forming a request:

• for OIDC — /authorize?client_id=...

• for SAML — AuthnRequest

2. The user's browser is then redirected to the Identity Provider (SSP).

3. On the IdP side, an initial check is performed: the system looks for the master_session_id cookie. In this scenario, the session is absent or expired, so the user is redirected to the login page.

4. After entering the login and password, the IdP does not verify the credentials itself but instead refers to an external identity source — for example, Active Directory, LDAP, or an external OIDC provider.

5. After successful authentication, a key step occurs — the creation of the master session:

• an entry with the status active is created in main.master_sessions

• an identical entry is saved in history (for audit purposes)

• a session expiration event is planned via NATS (delayed message)

• a successful login event is written to the audit log

6. If multi-factor authentication is enabled in the system, an MFA challenge is initiated. After confirmation:

• the mfa_verified = true flag is set in the master session

• an MFA success event is logged

7. Then the IdP creates a client session for the specific application:

• an entry is added in main.client_sessions

• it is duplicated in history

• a client session expiration event is planned

8. After that, the IdP forms a response for the SP:

• in OIDC — authorization code or tokens

• in SAML — SAMLResponse

9. The browser is redirected back to the application, which validates the response (signature, audience, expiration) and creates a local user session.

System state result

After the scenario is completed:

• an active master session exists in main.master_sessions

• a session for a specific SP is created in main.client_sessions

• history contains a full audit (login success, MFA success, session create)

• delayed session expiration events are in NATS

• the user is authenticated both in SSP and in the application

In fact, this is a "full cycle" of authentication with the creation of a basic SSO session.

Scenario 2: SP-initiated login with an active master session

Context: the user has already previously authenticated in the SSP, has an active master session, and clicks “Login” in the application again.

Sequence of Actions

1. The application (SP) also initiates a redirect to the IdP (/authorize or SAML AuthnRequest).

2. This time, the IdP detects the master_session_id cookie and finds the corresponding record in main.master_sessions with status active.

3. Next, the system evaluates the authentication context:

• whether the current trust level is sufficient

• whether an additional factor is required (step-up authentication)

4. If the security policy requires it, the user may be prompted for MFA. If not, the existing session is used.

5. The IdP creates a new client session associated with the existing master session:

• a record is added to main.client_sessions

• it is logged in the history

6. After that, the IdP immediately generates a response for the SP (auth code / tokens / SAMLResponse) and returns the user to the application.

7. The application validates the response and creates a local session.

System State Outcome

• the master session already exists, so no recreation is required

• a new client session is created for the specific SP

• the user gains access without re-entering login and password

• the audit logs the use of the existing session

This is SSO — quick access without re-authentication, while retaining control on the IdP side.

At first glance, SSO seems like a tool to simplify users’ lives. But in reality, its impact is broader. From the user’s perspective, things really do become easier: one login instead of dozens, less cognitive load, fewer password entry errors. But behind this lies a change in security architecture.

When authentication is centralized, it becomes possible to:

• Apply unified policies (for example, mandatory 2FA).

• Control all sessions from a single point.

• Quickly revoke access in case of termination or incident.

• Track user behavior across different systems.

For business, this translates into reduced risks and costs. The fewer passwords there are, the lower the likelihood of their leakage. The fewer manual operations, the lower the load on IT.

But it’s important to understand: SSO by itself does not make the system secure. If the only entry point is protected by just a password, then compromising a single password opens access to the entire infrastructure. Therefore, SSO is almost always used in conjunction with multi-factor authentication.

How SSO is implemented in MULTIFACTOR

In MULTIFACTOR, SSO is implemented as a full-fledged Identity Provider integrated into the multi-factor authentication system. The central element is the Self-Service Portal (SSP), which serves as the entry point, application showcase, and management interface.

In fact, SSP becomes the IdP through which all user authentication passes.

The user enters the portal, undergoes verification (login/password + second factor), after which a master session is created. This session is used to access all connected applications. Re-entering credentials is not required.

After authentication, the user sees a list of available services — only those to which they have rights. These can be both internal systems and external cloud services.

Protocol and Integration Support

MULTIFACTOR supports the main SSO protocols: SAML 2.0, OAuth 2.0, and OpenID Connect. This allows integration with almost any modern applications — from Microsoft 365 and Google Workspace to internal portals and custom-built systems.

Additionally, the system can work with LDAP directories (such as Active Directory or MULTIDIRECTORY), using them as a source of user accounts. This is important for building hybrid infrastructures, where authentication is centralized but user data remains in existing directories.

In scenarios with domain infrastructure, Kerberos can be used, which ensures “transparent” login for users within the network. MULTIFACTOR in this case adds the second factor at the stage of obtaining a ticket or accessing a resource.

What the authentication flow looks like

Let’s consider a typical scenario.

The user opens the corporate portal. Instead of the local login form, they are redirected to SSP. There, they enter their credentials and go through the second factor — for example, confirming the login via a push notification in the mobile app.

After successful verification, SSP creates a session and, depending on the protocol, issues either a SAML Assertion or an OIDC token. The user returns to the application, which checks the signature and validity of the token.

From this moment, the user is considered authenticated. If they open another application, it does not require re-entering credentials — the existing IdP session is used.

Thus, SSO in MULTIFACTOR is built around a single master session and trust from applications to the IdP.

Session and Security Management

One important aspect of implementing SSO is session control. In SSP, the administrator can view active user sessions, terminate them forcibly, or limit their lifespan.

This is critical in scenarios where it is necessary to quickly revoke access — for example, if there is suspicion of a compromise.

Additionally, MULTIFACTOR implements protection against typical attacks: password brute-forcing, session attacks, attempts to log in from suspicious IPs. All of this works at the centralized authentication point, simplifying control.

It is also worth noting that the system does not store user passwords — it operates on top of existing directories.

Practical Effect of Implementation

In practice, implementing SSO in MULTIFACTOR yields effects on several levels.

Users stop juggling passwords and work more quickly with the systems. The IT department gains centralized control and reduces workload. Security is enhanced due to the mandatory second factor and fewer entry points.

At the same time, the system remains flexible: it can be integrated into the existing infrastructure without changing the user directory or breaking current processes.

Single Sign-On is an architectural approach that moves authentication to a single controlled point and makes access management predictable and centralized. As a result, an important balance is achieved: one login for the user plus centralized control for information security.