Design Cross-Domain SSO and OIDC Access to Third-Party Tools

A business operates `foo.com` and has acquired `bar.com`. Users who sign in on either site should be able to reach the other site without entering their credentials again. Design the concrete login flow. Extend the design to multiple sites using OpenID Connect (OIDC), including access from the application to selected third-party tools. Explain authentication, local sessions, and the authorization needed for those tools. ### Constraints & Assumptions - `foo.com` and `bar.com` are distinct registrable domains; they cannot share a parent-domain browser cookie. - Practice clarification: each site can redirect users to a common identity provider and can implement a server-side login callback. - “Automatically logged in” means no second credential prompt while the common identity-provider session remains valid. Do not assume a hidden cross-site iframe will always have access to cookies. - The exact third-party integration is unspecified. Distinguish signing into a third-party application from authorizing it or the application to call an API. ### Clarifying Questions to Ask - Will the acquired site's accounts be migrated or federated, and how are existing accounts linked safely? - Does the third-party tool accept OIDC federation, expose OAuth-protected APIs, or both? - Which users may access which tools, and who grants or revokes that access? - Is logout local to one site or intended to terminate sessions across every site? ### Part 1 — Cross-Domain Login Flow Walk through the first sign-in on `foo.com` and the later visit to `bar.com`, including the browser redirects, identity-provider session, code exchange, and the local session created on each site. #### What This Part Should Cover - Why a shared identity provider solves the credential-prompt problem without sharing the two sites' cookies. - Authorization-code flow, transaction binding, token validation, and separate secure local sessions. - What happens when the identity-provider session has expired or a higher assurance level is required. ### Part 2 — Multiple Sites and Third-Party Tool Access Extend the architecture to many sites and explain how the application decides whether a user can access a tool. Describe both federation to a tool and delegated API authorization, without treating an ID token as a general-purpose API credential. #### What This Part Should Cover - Separate client registrations, redirect destinations, and session boundaries for each relying party. - Entitlement checks, appropriately scoped access tokens, and protected storage of delegated credentials. - Safe account linking and the effect of local logout, identity-provider logout, and revocation. ### What a Strong Answer Covers The browser flow, server exchanges, token purposes, and authorization decisions should fit together. A seamless user experience must still preserve domain boundaries and prevent one site's login artifacts from being replayed at another. ### Follow-up Questions - How would you handle an existing account on each domain that has the same email address but no verified identity linkage? - How would you keep the flow working when browsers restrict third-party cookies? - What can remain active after the user signs out of only one site?