Implementing SSO (Single Sign-On) for a Web Application

SSO for a web application: where login and permissions break

Single sign-on (SSO) stops being "just a login button" when a company has several systems: an employee directory, an internal portal, a CRM, a warehouse system, and accounting.

Each one lives with its own account database, and the moment a person leaves or changes roles, permissions remain hanging in three or four places. Authentication formally works, but logging into one system already opens up more than it should in another.

The first typical failure is account desynchronization. An employee was created in the directory but not in the application, or vice versa: a terminated employee continues to log in with an old token because the session lives longer than the record in the directory.

The second is manual password resets: support spends hours on "it won't let me into my account," even though the problem is an expired certificate or a skewed clock on the server.

The third failure is duplicated logins. A user creates a second account under a different email, and reports end up with two "identical" entities with different permissions.

The fourth is growing support load: the more systems there are, the more requests come in, and each new integration adds its own point of failure.

Let's break down how this gets resolved: a single authentication point, directory synchronization, and access revocation rules.

What single sign-on delivers: the effect in numbers

Single sign-on is measured not by convenience "in general," but by three metrics: time to access an application, the share of support requests related to access, and the number of password-related incidents.

Before implementation, an employee spends from 20 to 40 seconds logging into each system — entering a login, waiting for verification, retrying after an error.

With ten work services, that adds up to tens of minutes per week per person, and the losses grow linearly with the number of applications.

The main effect is the disappearance of a whole class of errors related to password resets. Based on our experience, password resets and access recovery account for 20 to 40 percent of all support requests.

After switching to single sign-on, the user authenticates once through a corporate account, and the application receives a verified session. Password-related requests drop severalfold — support shifts to tasks that genuinely require a human.

Login time is reduced to a single verification at the start of the workday: after that, switching between services happens without re-authentication.

For scenarios with heightened security requirements, we configure re-confirmation only for critical operations, not for every transition — protection is preserved, friction goes away.

The matter of offboarding and role changes is addressed separately: access is revoked at a single point, not in ten admin panels.

We work with proven federated authentication protocols and standard corporate directories — Keycloak as one of the broker options if full control over the infrastructure is needed.

This provides predictable integration with an existing user directory without rewriting applications. We record the effect before and after: we measure login time, calculate the share of access-related requests, and track the number of password-related incidents.

SSO implementation approaches: comparing options

Single sign-on is rarely built from scratch — more often a choice is made between a ready-made protocol, integration with a corporate directory, or a proxy gateway in front of the application.

The choice is dictated not by fashion but by the landscape: which systems already exist, where accounts are stored, and how deeply the application needs to know about the user.

What to look at when choosing

The key question is where the session lives and how the application learns about user logout. With federated protocols, a single logout is needed: without it, closing a session in one system leaves the others open.

For the internal perimeter, this is solved by binding to the directory; for the external one, by a short token lifetime and refresh on demand.

Separately, we check the mapping of roles and groups: attributes from the directory must be laid out into application permissions without manual synchronization.

If roles are maintained in two places, sooner or later they will diverge, and access will be granted to the wrong person.

What to consider regarding limitations

A proxy gateway saves time at the start but adds a point of failure and complicates debugging: the application stops seeing the real user context. SAML is reliable in a corporate environment, but each new application requires separate metadata configuration.

OpenID Connect is more flexible, but shifts part of the responsibility for token security onto the development team.

We analyze your system landscape and propose an approach that won't have to be redone as the number of applications grows. Describe your task — we'll come back with an estimate and a plan.

Stages of implementing single sign-on into the product

Implementing SSO is not "plugging in a library" but replacing the way identity is confirmed at every entry point without losing a single user and without opening a hole in access.

That is why we start not with code but with an inventory: which applications and services already use authentication, where accounts are stored, which protocols each component supports, and who owns each access. Without this map, any configuration turns into a lottery.

How the process works

1. Audit of current authentication. We compile a registry of applications, external services, and integrations, and record where sign-in is local, where it goes through a third-party provider, and where access is granted manually. We separately flag services that do not support the single sign-on protocol — for those we plan a workaround in advance.
2. Choosing the scenario and provider. We determine who acts as the source of truth about accounts: a corporate directory, an external provider, or an in-house database. This determines the user mapping scheme and the rules by which rights from the directory reach the applications.
3. Configuring the provider and applications. We register each application with the provider, configure trusted redirect addresses, session and token lifetimes, and attribute mapping. Here we also build in signing out of all systems with a single action — otherwise single sign-on remains half-finished.
4. Testing on a staging environment. We run through the scenarios: a new user's first sign-in, repeat sign-in, a role change in the directory, access revocation, session expiration, provider unavailability. We test each scenario across all types of accounts, including service accounts.
5. User migration. We transfer accounts and role links, and during the transition period we keep both sign-in methods so that no one loses access. We disable local passwords only after we have made sure that everyone has signed in via single sign-on.
6. Handover to operations. We establish the regulations: how to add a new application, how to revoke access upon termination, who is responsible for the provider. We set up sign-in logging and anomaly alerts.
7. Maintenance. We periodically review the list of connected services and the mapping rules — the set of systems changes faster than it seems.

Describe your current sign-in scheme — we will come back with an assessment and a work plan.

What the customer retains after implementation

SSO implementation is not a "set it and forget it" affair: the integration lives and changes along with your application landscape. That is why we hand over all artifacts to your infrastructure and repositories rather than keeping them to ourselves. Below is exactly what stays in your hands and how to use it without us.

• Identity service configurations — application connection parameters, session and token settings, rules for issuing and renewing credentials. Everything is in a version control system, with change history and rollback capability.
• Authentication flow diagrams — how a user signs in, where rights are verified, how an application receives identity confirmation. The diagrams cover both the normal scenario and behavior when the provider is unavailable.
• Access policies — mapping roles and groups to applications, rights inheritance rules, the procedure for granting and revoking access when an employee is hired, transferred, or terminated.
• Operations regulations — how to add a new application, how to onboard an external contractor, what to do when sign-in fails and where to look first. Step by step, with responsible parties and control points.
• Documentation — architecture description, list of connected systems, settings reference, change log. Written for an engineer who will open it six months later without us.
• Instructions for the support team — typical sign-in and access recovery requests, ready-made responses, and the boundary beyond which the technical team gets involved.
• Administrator access and rights — separation of roles between user management and configuration changes, so that day-to-day operations do not require full privileges.

This package eliminates the main risk: when SSO starts to live a life of its own, you have both a map of the terrain and the levers of control. Describe your task — we will come back with an estimate and a plan, including the set of artifacts to be handed over.

Case study: how we eliminated account desynchronization

The client — a service company with a distributed team — came with a classic pain point: several internal systems, each with its own user database. An employee was created manually in four places upon hiring, and upon termination their account was not disabled everywhere.

Over a quarter, about 40 "dead" active records accumulated, and the support service spent up to a third of its working time on password resets and sorting out access rights.

What it was like before implementation

Accounts lived in different systems independently: there was no single source of truth, and rights were assigned "by eye." Desynchronization manifested in two scenarios — a terminated employee retained access to some systems, and one transferred to another department continued to see data from their previous unit. Each such case was handled manually, reconstructing from logs where and when the records diverged.

What we changed

We built single sign-on based on Keycloak as the identity provider and connected all internal systems to it via a standard protocol. The employee directory became the single source of truth: an account is created once, and roles and rights are distributed through groups.

Disabling an employee now closes access in all systems simultaneously — it is part of the process, not a separate administrator task.

What it became after

The number of manual operations for creating and deleting accounts decreased by about 90%, and there were no "dead" active records left at all. Support requests about passwords dropped by almost threefold — employees log in with a single set of credentials.

The time to connect a new person to work systems decreased from several hours to minutes, and access auditing now takes a single query instead of manually going through systems.

How does SSO differ from identity federation?

SSO solves the problem of logging in within a single perimeter: a user authenticates once in a central service and gains access to applications that trust it. Trust here is built on a shared account and a shared store — a directory that holds logins, groups, and roles.

All applications are under a single administrative control, so aligning password policies, session lifetimes, and multi-factor authentication requirements happens within one team.

Identity federation works across different domains and different owners. The user remains in their own organization, and the partner service does not create an account on its side — it trusts an assertion of identity that is signed by the identity provider.

The key difference: with SSO, we manage all accounts ourselves, whereas with federation we only confirm the fact of authentication without gaining access to the user's password and profile.

This leads to different implementation requirements. For SSO, a single directory and a protocol for passing the session between applications in one domain are sufficient.

For federation, you need metadata from both parties, an exchange of signing keys, and pre-agreed attributes — exactly what information about the user is transmitted and in what form.

An error in attribute mapping results in the person logging in but not receiving the necessary permissions.

In practice, these models are often combined. Inside a company, SSO is deployed, while for external partners and contractors, federation is configured so as not to issue them accounts in your own directory.

The boundary between the approaches comes down to the question: who owns the account and who is responsible for its lifecycle — creation, blocking, and deletion upon termination of employment or contract.

Technical concerns when implementing SSO

Questions at the stage of choosing a protocol and integration scheme always arise — and that's normal: the answers determine how SSO will fit into the current application landscape and whether it will break login for existing users. Below are the things we most often discuss with technical teams before starting work.

What about security: won't a single point of entry become a weak link?

On the contrary — SSO eliminates the main vulnerability where users keep different passwords or reuse one. Authentication is concentrated in one place, where multi-factor verification, IP restrictions, and login logging can be enabled.

The key is to correctly configure token lifetimes and their revocation on logout, so that the session does not remain active across all applications after logging out.

How will the migration go — will everyone have to be forced to change passwords?

Not necessarily. Accounts are transferred, and passwords can be synchronized through federation with the current store or old-password login can be kept during a transition period.

Usually we launch SSO in parallel with the previous login, migrate one application at a time, and disable the old scheme once we are sure all login scenarios work. Rollback at any step means returning to the previous configuration without losing accounts.

Who will get access to user data and how is this regulated?

The identity provider stores only the attributes needed for login and roles — the rest of the data remains in the applications.

Rights are assigned by groups rather than manually, so when an employee leaves or changes roles, access is closed in one place and immediately across all systems.

Let's discuss your single sign-on task

Before proposing a solution, we need to understand your current picture: which applications and services are already in use, where accounts are stored, and how roles and access rights are structured.

This determines whether single sign-on will be an add-on on top of an existing user directory or will require rebuilding the access model.

So the first step is a short scoping session together with your team: which systems should participate in SSO, who manages users today and how, and which sign-in scenarios are critical.

Based on the scoping results, we come back with an estimate and an implementation plan — with phases, timelines, and areas of responsibility.

You don't need to prepare a detailed technical specification: it's enough to describe the task and the current landscape; we'll structure the rest ourselves.

What you'll get at the start of the work:

• A review of the current authentication scheme and the points where it fails.
• A list of applications and services that will be included in single sign-on, with connection priority.
• A role and permissions model: who gets access to what and how this changes upon termination or transfer.
• SSO implementation options for your landscape — with the pros and limitations of each.
• A user migration plan with no downtime and with the ability to roll back.
• A list of risks: incompatible systems, legacy applications, external contractors.
• An estimate of timelines and scope of work by phase.

Describe the task — which applications need to be unified, how many users, whether there are external partners, and security requirements. We'll come back with an estimate and an implementation plan that you can use to make a decision.