Single sign-on is the feature that appears in the security questionnaire of your first serious enterprise deal, framed as a requirement rather than a preference. The buyer's reasoning is sound - they want employees provisioned and deprovisioned centrally, and an account they cannot revoke when someone leaves is an audit finding. Understanding what they actually need saves a great deal of guesswork.
There are two protocols and the choice is usually made for you by the customer. SAML is older, XML-based, and remains what most large enterprises run because that is what their identity provider was configured for a decade ago. OpenID Connect is modern, JSON-based, considerably more pleasant to implement, and increasingly common. If you build one first, build SAML, because the customers demanding SSO are disproportionately the ones on SAML.
The implementation itself is well-trodden and you should not write it yourself. Signature verification, assertion validation, replay prevention and clock skew handling are all places where a subtle mistake produces an authentication bypass rather than an error. Use a maintained library, or one of the services that normalise both protocols behind a single integration - for a small team, that is usually the correct build-versus-buy answer.
The work that surprises teams is the account model, not the protocol. Do users belong to an organisation, and is that organisation bound to an email domain? What happens when someone already has a personal account and their employer enables SSO - do you merge, and on what evidence? Can an organisation require SSO and disable password login for its members? Retrofitting these questions onto a user table designed for individual signups is most of the effort.
Provisioning is the other half and is what the buyer actually wanted. SSO governs how someone logs in; SCIM governs who exists. Without automatic provisioning, an administrator still creates and removes accounts by hand, which is the problem they were trying to solve. Expect SCIM to be the follow-up request roughly one quarter after SSO ships, and design the account model with it in mind.
One commercial note worth being deliberate about. There is a long-running argument about putting SSO behind an expensive enterprise tier, on the grounds that it is a security feature rather than a luxury. Whichever side you take, take it consciously - buyers have become alert to it, and a company that charges several times more for the ability to revoke a departing employee's access should expect that to be raised in negotiation.
