Single Sign-On

Twelve tools at work means twelve accounts. Nobody remembers twelve passwords, so one gets reused everywhere or written down somewhere convenient. Leak any one of them and the other eleven open with it.

The administration side hurts differently. Someone joins and twelve accounts get created; someone leaves and twelve have to be found and cut off. In practice the cutting off is what gets skipped. That is how a departed employee's account stays alive in a collaboration tool for six months.

Sofia met this as the first question in a conversation with a 200-person customer. Ahead of features and ahead of price came "can people sign in with their company account?" A no ended the evaluation on the spot, because the customer's security team will not approve a tool whose accounts can't be managed from one place. The question arrives before anyone has looked at what the product does.

Single sign-on consolidates authentication into one location. Authentication is the process of confirming who someone is. Rather than each service checking for itself, each one asks the single place the company designated and takes the answer. Twelve accounts become one account with twelve doors attached to it.

There isn't much for the implementing side to decide, because the customer's existing setup dictates most of it. The work instead repeats per customer, which is where the real cost sits.

1. Identify the identity provider. That's the account system the customer already runs, and it vouches for who a person is. You aren't choosing it; you're matching whatever they use.
2. Choose the protocol. Enterprise environments commonly run SAML, while newer services lean toward OpenID Connect (OIDC). Supporting both means no customer gets excluded.
3. Exchange configuration. Your addresses get registered on their side and their certificate on yours. It's a handful of copy-and-paste steps, and left unautomated it eats thirty minutes per customer.
4. Map user attributes. Decide which of the values the identity provider sends becomes the email and which becomes the name. When the customer also sends group membership, that can be translated into roles on your side.
5. Test sign-in from both directions: the user starting on your screen, and the user clicking your service inside the customer's portal. Skip the second and half the real users can't get in, and the support tickets that follow all read as though sign-in is broken.
6. Connect account creation and removal. Accounts appearing on hire and switching off on departure, automatically, is what actually solves the administration problem described above.
7. Leave an emergency path. If the identity provider goes down nobody can get in, so one or two administrators keep password access.

The sign-in itself flows in five steps. A user arrives at your address, you redirect them to the customer's identity provider, and if they already have a session there they pass straight through; otherwise they sign in and satisfy multi-factor authentication. Multi-factor authentication confirms identity through two or more separate means. Once that clears, a signed response comes back to you, and you verify the signature and create a session.

Where it pays is clear enough: organizations with many employees, industries audited on account management, companies running more than ten tools. For those customers this isn't a feature but a contract term, which is why it commonly sits on the enterprise plan only. Offering it on lower tiers gives away the one thing large accounts will pay a premium for.

Five limits come with it.

1. One outage stops everything. When the identity provider fails, every person at that company is locked out of your service.
2. Configuration differs per customer. The protocols are standards, but attribute names and address formats vary just enough that support volume climbs with each new customer.
3. Sign-out isn't clean. Ending your own session does nothing if the identity provider session is still alive — the user walks straight back in. A protocol-level global sign-out exists, and implementations of it vary widely enough that it cannot be relied on.
4. It's useless to individual users. Someone without a company account has nothing to connect, so consumer-facing products get no value from building it.
5. It doesn't solve authorization. Authorization is the process of checking what someone is permitted to do, and the identity provider only says who they are. Permissions still get decided on your side, typically through role-based access control.

"This customer won't sign without SSO. Put it in the enterprise plan terms."

It's a condition of the deal rather than a feature request.

"We never built the flow that starts from their portal. That's the default route for them."

Only one direction got implemented, so real users can't get in.

"We connected SSO and we're still granting permissions by hand."

Authentication is wired up and authorization is untouched.

Pagedeck put this on the enterprise plan only. Theo built one of the two protocols first, and then Sofia found three of five customers in conversation were running the other one, so the second got built too.

What Grace checked was the removal side. Connecting sign-in does keep a departed employee out, but the account left behind on Pagedeck's side was still counting toward the paid seat total. So removal in the identity provider now switches off the local account as well, and the seat count matches the customer's actual headcount.

The most common reading treats it as the same thing as social login. Both sign people in using an account held elsewhere, so on screen they look alike. What differs is who controls the account. Social login is an individual arriving with their own account; single sign-on is a company controlling its employees' accounts. Whether switching off the account also cuts off service access is the dividing line, and the second is what enterprise customers are asking for.

Expecting it to make things more secure by itself is also frequent. Security teams ask for it, so it sounds that way. All the approach itself does is consolidate the checking into one place. What raises security is the multi-factor requirement and the access conditions attached to that place, and consolidating into something weak consolidates the risk too. Wire it to an identity provider guarded by one password and you have gone from twelve doors to one, which is easier to break into, not harder.