SSO for the Corporate Intranet: How to Onboard 1,200 Employees in a Week Without Breaking Anything

A corporate intranet that users log into with a separate username and password is automatically a dead intranet. Per our clients' data, the DAU of such portals drops below 30% within three months of launch. The reason is simple: another password nobody remembers, another tab that gets closed.

This article is for the IT director choosing or deploying an intranet, and for the HR director curious about what technically needs to happen to launch a portal "the grown-up way." No jargon, but no oversimplification either: SSO is a decision made of a dozen smaller decisions, and each is worth understanding.

We'll go layer by layer: why SSO is needed in principle, which protocols to choose in 2026, how to set up JIT provisioning, the role of a custom domain, and what a 5-day deployment playbook looks like.

Why SSO — Three Reasons, Not One

SSO is often sold as "a feature for the security team." In reality it solves three different problems, and underestimating any of them is a mistake.

First — UX. An employee logs into email, chat, the task tracker, cloud storage — everywhere through the corporate account. If the portal demands a separate login, it stands out from that lineup. That's the cause of those 30% DAU numbers. One login for everything isn't "convenient" — it's the minimum acceptable standard in 2026.

Second — security. One password is easier to protect than ten. If an employee has a separate portal login, they'll probably set "qwerty2024" and never change it for a year. If all systems are behind SSO, there's one password, protected centrally (with 2FA, regular rotation, a complexity policy), and a compromise of the portal password automatically becomes an incident across the whole stack, not a single app.

Third — clean offboarding. When an employee leaves, their IdP account is blocked, and within the same minute they lose access to all systems, including the portal. Without SSO, you have a list of 15 places where the user must be removed manually — and at most companies that list never gets fully completed. Former employees stay in the portal for months, sometimes years, which is already a formal data-protection violation.

These three reasons aren't alternatives, they're layers. SSO is needed for all three at once, and the decision "we'll go without SSO for now, add it later" usually turns into "the portal's been running for a year and we never got around to SSO."

SAML vs OIDC vs LDAP — What to Choose in 2026

Three main protocols you'll encounter during setup. The basic differences matter.

LDAP — an old protocol that survives in infrastructures with a long-standing Active Directory. If everything's already on AD, the portal can integrate with it, but it's a compromise. LDAP works poorly with mobile clients and barely works with distributed teams. Avoid it in new deployments.

SAML 2.0 — the standard for enterprise integrations over the last 15 years. Most IdPs (Okta, Azure AD, Google Workspace, Keycloak, ADFS) support it at minimum. Complex to integrate, XML-based, but reliable and battle-tested. At large companies with mature security, often a requirement.

OIDC (OpenID Connect) — the modern protocol, built on top of OAuth 2.0, using JSON and JWT tokens. Simple to integrate, designed for mobile clients from the start, easily scaled across different apps. All new SaaS products (including us) offer OIDC as the first option.

Our recommendation for 2026:

• First choice — OIDC. If your IdP supports it (and almost all modern ones do), take it.
• Fallback — SAML 2.0. If you have an old IdP without OIDC, or security mandates SAML by corporate standards.
• LDAP — only if there's no other way. For example, you have on-prem AD with no modern tooling around it.

A good corporate portal should support all three protocols, so as not to dictate to the client how to handle their infrastructure. But a new client is almost always OIDC.

JIT Provisioning — No Manual User Import

The most painful part of classic portal onboarding is manually creating users. HR writes to IT, "here's a list of 12 new employees, set them up in the portal," IT does it 2 days later, HR checks and finds half were missed, IT finishes up, and meanwhile turnover keeps going.

The solution is Just-In-Time provisioning. The user is created in the portal at the moment of their first SSO login, based on data from the IdP. No lists, no emails, no manual import.

What gets mapped at JIT:

• Name — from the IdP (given_name, family_name, or name).
• Email — the primary identifier.
• Department — from an IdP attribute (e.g., department in Azure AD, or from group membership).
• Job title — from an IdP attribute (jobTitle).
• Portal role — based on IdP group membership. If a person is in the hr-team group, they get the HR manager role. If in tech-managers, Team Lead. If in none, the default value.
• Photo — from Microsoft Graph, Google Directory, or an equivalent.

Edge cases to think through in advance:

• What to do if the user has no mappable group. A default role (usually "Employee"). No "you can't log in, contact your admin" — that's the same barrier as manual setup.
• What to do if the department attribute is missing. A "No department" section is better than a login error.
• What to do if changes came from the IdP (e.g., the user was moved to another department). Re-sync attributes on every login — this lets you quickly correct roles without manual intervention.

JIT isn't a nice-to-have. On a team of 100+, manual provisioning is +1 person on the IT team dealing with lists daily. JIT removes that work entirely.

Enforced SSO and a Custom Domain

Two details often deferred "for later," yet they're exactly what separates a mature deployment from a pilot.

Enforced SSO. This is a toggle in the portal admin panel: "email + password are no longer allowed, only via the IdP." Why it's needed: without enforced mode, orphan accounts still get created in the system — users who once logged in with a password and keep using it, bypassing SSO. A year later your database has 30 "shadow" users the IdP doesn't see and HR doesn't know about. With enforced SSO, that doesn't happen — everyone goes through SSO, and SSO is the single point of control.

It's usually enabled in one click after the SSO flow stabilizes (so you don't cut off anyone whose setup hasn't arrived). Good practice — two weeks of hybrid mode (SSO + password), then enforced mode.

A custom domain. portal.yourcompany.com instead of yourcompany.teamhero.com. Seems minor — but it affects perception.

Why it matters:

• Trust. An employee who sees a tab with their company's domain trusts it by default. A third-party SaaS-vendor domain is psychologically a little "not mine."
• Consistency. In corporate documentation, email invitations, and onboarding materials, links look like portal.yourcompany.com/... — that reads as part of the company's infrastructure.
• Control if you change vendors. If you ever need to migrate, DNS switches over and users keep going to the same domain.

Technically: a TXT record to verify ownership, a CNAME to the vendor's infrastructure, automatic SSL certificate issuance (Let's Encrypt or equivalent). With mature vendors this takes 30 minutes from start to a working domain.

A 5-Working-Day Deployment Case

The standard playbook we offer clients with teams of 500–1,500 people: a five-day deployment schedule for Azure AD / Keycloak / Google Workspace, in a typical scenario without serious incidents. This isn't a marketing promise: SSO is considered one of the most predictable integrations in enterprise systems — per a Gartner survey, 70% of companies name improved user experience as SSO's main benefit, and 61% cite fewer IT-support tickets.

Day 1 (Monday). Kickoff with the client's IT team: choosing the IdP (Azure AD in our case), the attribute format, the role mapping. An hour of conversation — we leave with a ready spec.

Day 2. Creating the OIDC client in Azure AD, configuring the callback URL, registering it in the portal. Test with 3 users (usually the IT director, the HR director, and one volunteer). At this stage we catch the most obvious problems (wrong scope, missing attribute).

Day 3. Configuring JIT mappings: which IdP attribute maps to which portal field, which IdP group maps to which role. Edge cases (no group → default, no department → "No department"). Verification with another 5–10 users.

Day 4. Pilot with one department (~30 people). The department's team uses the portal via SSO through the day, and we collect all the small bugs (attribute didn't arrive, photo didn't load, wrong role). We fix them.

Day 5 (Friday). Rollout to the whole company. An email notification to employees — "the portal now works through your corporate login." The old email+password authentication stays enabled for 2 weeks as a fallback. After 2 weeks, enforced SSO turns on and the old logins are disabled.

The typical outcome of such a five-day deployment: enforced mode after 2 weeks, and noticeably higher portal DAU within a month. The effect comes from a lower login barrier: one corporate login versus a separate password the employee forgets. This aligns with industry observations that after SSO, "forgot password" tickets drop and login frequency rises for systems that were previously used only occasionally.

The Bottom Line

SSO isn't "a feature for the security team," it's the baseline infrastructure of a corporate portal. Without it, the portal loses 50–70% of potential DAU and creates a tail of orphan accounts after departures.

Three practical takeaways for 2026:

• Prefer OIDC. More modern, simpler, mobile-friendly. If the IdP allows it — no SAML.
• JIT provisioning is mandatory. No manual lists. The user is created on first login, the role is determined by the IdP group.
• A custom domain from day one. portal.yourcompany.com isn't cosmetics, it's an employee's baseline trust in the system.

And a separate point: if you're deploying for a team of more than 100, plan 5 working days for SSO from the kickoff. Less is optimistic; more is usually a drag caused by internal security sign-offs. Five working days is a realistic, proven benchmark.

Next, on data-protection law and AI in HR tech: what's allowed and what isn't in 2026, and how to pass a compliance review before buying an AI system.

If you need a detailed technical one-pager on SSO for your specific IdP (Azure AD, Okta, Keycloak, Google Workspace, ADFS), get in touch and we'll send a targeted document with configuration examples.