Why You Should Avoid Identity Sync Like Wildfire?
summary
Engineers build a BoostAuth SSO that initially copies users between dual databases and implements a fragile SCIM subset, which produces UUID mismatches, validation errors and manual resyncs that lock people out. An alternative proves simpler: centralize identity, store UUIDs in SAML responses and include an authorization flag (SAML with UUIDs and authz flag), migrate passwords in-place, and optionally notify services via webhook optional sync so replication and painful identity-sync failures disappear.
AI-written summary · about
chapters (16)
- 0:00Why You Should Avoid Identity Sync Like Wildfire?
- 1:03The Engineer's Tale: Beginnings
- 2:58The Engineer's Tale: Boost SSO
- 4:24The Engineer's Tale: Expansion
- 5:32The Engineer's Tale: Brave New World of BoostAuth
- 8:05The Engineer's Tale: The Promise of Gold
- 10:19The Engineer's Tale: Building the Gate
- 11:54The Engineer's Tale: New Service Providers
- 12:52The Engineer's Tale: More Mismatch Nightmare
- 16:26The Engineer's Tale: Sync and Sync Some More
- 19:36The Magician's Tale: Her Secret Weapon
- 20:53The Magician's Tale: The Future Lessons
- 22:00The Magician's Tale: Reflections
- 24:59The Magician's Tale: The New Design
- 30:26The Magician's Tale: The Flow
- 32:39The Magician's Tale: The Solution
related talks
01h 12mIdentity 2.0: the what, why and how of social and federated login
43mMismatching Core Identity Stores After Recovery!
40mWhy are you still managing users? Identity has a cloud version
30mOMG WTF SSO: A Beginner’s Guide to Single Sign-On...
51mYou Shall Not Password: Modern Authentication for Web Apps
45mWhy We Should Kill Saml2
46mSecure SSO Authentication: Strategies to Eliminate Vulnerabilities
37mCustomer Identity for Modern Apps and APIs