Estimating an SSO integration

OAuth, SAML, OIDC. The story whose size depends entirely on which identity provider, and what kind of quirks it has.

SSO is mostly someone else's quirks. Spike the IdP first; the rest is yak shaving.

"Add SSO" reads like one feature. It's two. The first is a small piece of OAuth or SAML or OIDC plumbing — well-documented, libraries exist, every modern auth library has a tutorial. The second is everything the identity provider does that isn't in the tutorial: the claim names that don't match the spec, the redirect URI rules that are stricter than the spec, the session timeout that doesn't match yours, the off-by-one in how groups get serialized, the metadata endpoint that returns invalid XML on Tuesdays. The first part is the story everyone can vote on. The second part is the points.

Which means the estimate isn't really about SSO. It's about this IdP, and whether anyone on the team has integrated against it before. Okta with a vanilla SAML config is a different story from Azure AD with a custom claims rule that nobody on either side fully understands. A team that ships an Okta integration in a sprint will spend three sprints on a federated AD FS deployment with a custom proxy in front of it, and the codebase that gets written looks almost identical at the end.

What gets said in the room

Backend: "It's an OAuth flow. Library handles it. 5 points."

Security: "Which IdP? Okta? Azure AD? Custom SAML?"

Backend: "...does it matter?"

Security: "Yes. Their claims aren't the spec's claims."

Lead: "Has anyone on this team integrated with their IdP before?"

SRE: "What's the rollback if it breaks for half our users?"

The lead's question is the one that decides the estimate. If someone on the team has shipped against this IdP, the story is small and well-bounded. If nobody has, the story is two unknown-shaped pieces of work, and the right move isn't to estimate harder; it's to time-box a spike against the IdP's actual behavior and size the implementation after.

Questions worth asking before voting

  • Which IdP, specifically? Okta, Azure AD, Google Workspace, Auth0, custom?
  • Has anyone on the team integrated against this IdP before?
  • OAuth, SAML, or OIDC — and which version of each?
  • What's the user-provisioning model — JIT, SCIM, manual?
  • Group-to-role mapping: do we need it? Where does the mapping live?
  • What happens to existing local accounts during cutover?
  • Session timeout, idle timeout, MFA enforcement — whose policy wins?
  • Can we test against the customer's actual IdP, or only against a sandbox?

Most of these questions have answers that are either "trivial" or "this is its own ticket." The estimate is a function of how many "this is its own ticket" answers come back. If the count is two or more, the story is too big; split out provisioning, role mapping, and migration as their own stories and size the auth flow on its own.

Don't vote a number until you know whose IdP you're integrating against. The IdP is the story.

See estimating a third-party API swap for the related "someone else's quirks" pattern; what is a spike for the IdP investigation that should precede the implementation estimate. Open a session once the spike has answered which IdP and which quirks.