Design Single Sign-On Across Two Acquired Sites With OIDC Federation

A company runs north.example.com and has just acquired south.example.com, a separate registrable domain with its own existing user base. Whichever of the two sites a user authenticates on first, visiting the second one shouldn't prompt them for a password again. Work out, step by step, the mechanics that deliver that experience.

Then stretch the same architecture across an arbitrary number of sites, built on OpenID Connect (OIDC), and add the ability for the application to reach selected third-party tools on a signed-in user's behalf. Be explicit about the difference between a user signing into a third-party tool versus the application being authorized to call that tool's API.

Constraints and Assumptions

• north.example.com and south.example.com are distinct registrable domains and cannot share a single browser cookie.
• Each site can redirect the browser to a shared identity provider and can run a server-side callback to complete login.
• "No second credential prompt" means no second password entry while the shared identity-provider session is still valid — don't assume a cross-site iframe can silently read another site's cookies.
• The third-party tool integration is open-ended: distinguish federating a user's identity into a tool from authorizing the application to call that tool's API independently of any specific user being present.

Clarifying Questions

• Are south.example.com's existing accounts migrated outright, or federated and linked to existing north.example.com accounts over time — and how is that linkage done safely?
• Does the third-party tool support OIDC federation, expose OAuth-protected APIs, or need both?
• Who decides which users can reach which tools, and who can revoke that access?
• Should logging out end the session on just the current site, or everywhere at once?

Part 1 — The Two-Site Login Flow

Walk through a user's first sign-in on north.example.com and their later visit to south.example.com: the browser redirects, the identity-provider session, the code exchange, and the separate local session each site ends up with.

What this part needs to cover: the reasoning for why one shared identity provider removes the repeated-login problem even though the two sites can't share a cookie; the authorization-code exchange detailed enough to show how you bind the transaction and validate the returned tokens; and the fallback behavior when the identity provider's own session has already lapsed before the second site is visited.

Part 2 — Many Sites and Delegated Tool Access

Extend the design past two sites to an arbitrary number, and describe how the application decides whether a given user can use a given third-party tool. Cover both federating identity into a tool and obtaining delegated authorization to call a tool's API, and explain why an ID token alone is the wrong credential for the second case.