1 week to SSO with Stytch

At Orb, we build a scalable billing system so we're in the business of handling sensitive revenue data, and accordingly have an obligation to take security and data protection seriously. We do so by keeping our security-sensitive surface area small and by delegating to experts whenever possible: audit firms, penetration testers, and vendors.

With this framework in mind, we set out to build a single sign-on solution for Orb. We, like many companies, need a solution that can control customer data access effectively, to reduce maintenance burden with organizational changes and avoid costly mistakes. The mechanism that’s emerged for that is the identity provider (e.g. Okta), which provides a point of control over data permissioning. 

On Day 1 at Orb, we implemented Auth0 for user login and session management. Although Auth0 did the job and we knew we’d be able to expand its use to cover SSO and SAML, we’d seen enough instances of degraded performance and stability that it was time to wind down our relationship. Having personally worked on hand-rolled SSO and SAML for years in prior roles, I sure wasn't ready to keep up with RFCs and custom libraries for parsing SAML assertions. I can tell stories for hours about obscure XML, only to find regressions in JS SAML libraries.

Migrating to Stytch

When we started exploring Stytch as an option, we were immediately impressed by the team’s thoughtful documentation, responsive support on the community Slack channel, and the quality of the SDKs which would effectively be a drop-in replacement for Auth0. Months ago, I’d also personally consulted with the Stytch team on the trickier parts of the B2B engineering spec for just-in-time provisioning and SCIM, so I knew their roadmap was aligned with how we wanted authentication to work at Orb.

We outlined a few priorities going into the migration:

• Backwards compatibility: We needed to ensure that we could temporarily support both the existing Auth0 implementation and Stytch during the rollout and that we had a robust rollback mechanism. We wanted to be extra sure that no users would notice the change in auth provider at all, so data migration needed to go smoothly.
• Outsourced session management: With Auth0, we were able to offload session management (i.e., is this client currently logged in? When does its session expire, and can it be refreshed if it’s still valid?). Building session management functionality in-house was possible but would’ve added significantly to both engineering cost as well as security-sensitive surface area.
• Fewest moving parts: As a principle, we wanted there to be ‘one blessed path’ for implementing authentication handling; any unnecessary branching across different authentication methods would lead to a more complex codebase. Especially in this domain, complexity is the enemy.

Stytch’s primary responsibility is to abstract away the semantics of the specific identity provider, giving Orb’s developers a simple interface for business logic. Here’s how the separation of responsibilities looks for Orb for a sample SAML request to Okta:

It’s remarkable how much work well-thought-out abstractions can do for you. Since Stytch handles the initial request to determine available login methods, requiring SAML or Google login is as simple as flipping a bit via Stytch’s API, as is gating which authentication methods can be used for just-in-time provisioning (i.e. account creation on first login). Stytch also entirely removes the need for us to keep up with any breaking changes that Okta, OneLogin, or Azure may introduce since it consumes those redirect flows.

We were delighted to discover only a couple of surprises in this week-long migration process:

• Although Stytch has some drop-in UI components for login, they didn’t fit Orb’s constraints neatly. That being said, Stytch’s headless SDK made it incredibly easy to create our login and forgot password flows by layering our UI design on top.
• The frontend and backend SDKs worked in concert more smoothly than we’d expected - we were able to initialize the client SDK with a server-retrieved token (for example, from an SSO redirect flow) in the same way the client would initialize itself after password login, reducing the amount of branching in our authentication code.

Before launching SSO broadly, we conducted a multi-day gray-box security audit with our penetration testing partner Doyensec, exported our Auth0 password data into Stytch, and did a final flag change to start exclusively relying on Stytch. 

What’s next

We’ve launched SAML and SSO as part of our Enterprise tier, but it still requires a 10-minute onboarding session with our team to configure the identity provider connection. Over the next few weeks, we’ll be making that entirely self-serve with the help of existing and new admin controls from Stytch’s B2B authentication offering. Thanks to their support, we’re in a good position to chart full production support for other enterprise-critical features such as SIEM audit logging and sophisticated role requirements.

‍