SSO Callback and Session Establishment Flow

Introduction

The previous article covered how the sending side issues a signed handoff token. This article is the sequel: what the receiving side does.

From the moment the token arrives at the receiving site's callback URL until the user is displayed as logged in, there's a sequence: verify, create a session, and send them back where they came from. It looks mundane, but the safety and quality of the SSO experience are actually decided by how well this callback side is built.

What the Callback Receives

The Callback URL as an Entry Point

Each site has a dedicated entry point (a callback URL) for receiving handoff tokens. The sending side redirects the user to this URL with the token attached.

This callback is less a back door than a "locked front door." Anyone can access it with a token-like string attached, so you must never trust what you receive unconditionally. It starts with verifying it thoroughly.

It Also Receives a Return Destination

Along with the token, the callback often receives "which page to return to after login." The user may have clicked the link because they wanted to see a specific product page on Site B. We honor that intent and deliver them to the place they originally wanted once auth is done.

But this return destination also needs checking for whether it was rewritten to a malicious external URL. We insert checks such as restricting it to paths within our own site. It's a small thing, but this kind of care quietly pays off, doesn't it?

Verifying the Token

Three Checks in Order

Before creating a session, we always verify the received token. The "signature, expiry, single-use" built into the handoff token are confirmed here in order.

If even one of these fails, we error out on the spot and create no session. "When in doubt, reject" is the iron rule. Only after passing all three do we decide this token is trustworthy.

Handling Verification Failures

Showing detailed failure reasons on screen gives attackers hints. Keep the details in the logs while minimizing what's shown to the user. That balance matters.

Establishing a Session and Returning

Create the Site's Own Session

Once verification passes, Site B finally creates its own session. This is the crux of SSO: rather than reusing Site A's session as-is, Site B rebuilds login state on its own side, based on the user identifier received in the token.

The session cookie issued this way functions exactly like a normal login within Site B from then on. Since the backend Shopify store is shared, points and member pricing carry over as they are.

Redirect to the Original Destination

Once the session is established, we deliver the user to the return destination we saved at the start. Only here does the smooth experience come together in the user's eyes: "I clicked a link and the page I wanted opened, already logged in."

Behind the scenes, verification, session issuance, and redirect run through several stages, yet it feels instantaneous. That "unnoticed smoothness" is, I think, the answer to whether the SSO was designed well.

The Whole Thing on One Sheet

Conclusion

The callback side's job was to "distrust the received token, and if it's valid, create the site's own session and return the user to their original spot." To recap:

1. Don't trust unconditionally: the callback is a front door. Start with verification
2. Three checks: pass signature, expiry, and single-use, all of them
3. Rebuild the session: since cookies can't cross domains, issue it on your own domain
4. Fail gently: abandon SSO for normal login, reveal no details

The token design itself is in "How Signed Handoff Tokens Work," and where SSO fits overall is in "Single Sign-On Across Multiple EC Sites." Configuration management for adding sites is in "SSO Configuration That Scales with New Sites."