This past week has been a whirlwind of learning and implementation as I tackled Google, GitHub, LinkedIn, and Apple OAuth integrations for our products, including LiveAPI.
With the feature release day fast approaching, I’ve realized it’s not just about adding new authentication methods to our existing sign-in process — it’s about rethinking the entire architecture to support them seamlessly.
The Old System: Solid, But Limited
Previously, we relied on a robust SSR (Server-Side Rendering) system.
It bundled our sign-in process into an internal npm package that each of our frontend apps could use.
The apps would render the sign-in page using an iframe, which pulled in JavaScript from an HTML string.
This setup worked fine for OTP-based authentication and Google Sign-In.
But as I delved into adding OAuth for LinkedIn and GitHub, we hit some critical roadblocks:
Content Security Policy (CSP) Restrictions: Platforms like LinkedIn and GitHub enforce strict CSPs. For example:
- "Content Security Policy directive: \"frame-ancestors 'none'\"."
- "Refused to frame 'https://www.linkedin.com/' because an ancestor violates the following Content Security Policy directive: \"frame-ancestors 'self' .www.linkedin.com:\"."
These restrictions meant that the iframe-based approach was no longer viable.
A New Direction: Centralized Authentication
We needed a solution similar to what Google or Zoho use: a centralized login system hosted on one site, allowing other apps to redirect users there for authentication.
This approach would solve the CSP issues and pave the way for a smoother, more scalable integration of additional OAuth providers.
With this in mind, I planned to:
- Migrate the existing OTP and Google Sign-In to the new centralized system.
- Simultaneously add LinkedIn and GitHub OAuth.
My initial thought was to merge all these changes and release them together after thorough testing.
But then, a conversation with my senior convinced me I was wrong.
The Risk of Big Bang Releases
Releasing all changes at once seemed efficient, but my senior helped me understand the risks:
Replacement Risks: Migrating the existing OTP and Google Sign-In to the new system could introduce unexpected issues in production. If something broke, we’d need to deploy a quick patch.
Compound Risks: Adding new features (LinkedIn and GitHub OAuth) alongside the migration doubled the risk. If any part of the release failed, it could affect both the new features and the existing functionality.
Instead, my senior suggested minimizing risk by:
- Breaking the release into smaller, incremental updates.
- Deploying the replacement (OTP + Google) first. If issues arose, they could be fixed quickly without affecting the new features.
Deployment Strategies: Canary Releases and Canary Deployments
This involves:
- Rolling out the new feature to a subset of users.
- Testing its functionality and comparing analytics (e.g., NPS, user abandonment rates) against the existing system.
- Gradually expanding the rollout once the feature proves stable.
Alternatively, we can use a Canary Deployment strategy, which works similarly but focuses on traffic splitting rather than targeting specific user groups. This approach is particularly effective for backend changes where user feedback isn’t as critical.
Feature Flags: A Bonus Tool
I also explored the use of feature flags to control the rollout of new features dynamically. Feature flags allow us to:
- Enable or disable features without deploying new code.
- Target specific users or user groups.
- Roll back changes instantly if issues arise.
For more on feature flags, check out this guide.
Takeaway: Minimize Risk with Gradual Deployment
In the end, the key lesson was clear: minimize risk by breaking down large releases into smaller, manageable updates.
Whether through Canary Releases, Canary Deployments, or feature flags, incremental deployment strategies help ensure stability and provide valuable insights before a full-scale rollout.
With these strategies in place, I’m confident in delivering a smoother, more reliable authentication experience for our users — one step at a time.