Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Complete a technical breakdown for decommissioning Tokenserver #1582

Open
data-sync-user opened this issue Jul 3, 2024 · 3 comments
Open

Comments

@data-sync-user
Copy link
Collaborator

Let’s plan and breakdown in detail how we will accomplish the decommissioning of Tokenserver: https://docs.google.com/document/d/1gYy875bIYASuGDhoJYUYOBUMy73yH_eyXXu1Br3iw5s/edit#heading=h.5r69rom8w46i

┆Issue is synchronized with this Jira Task

@Eragonfr
Copy link
Contributor

Can this doc be made public ? I'm interested in following how tokenserver evolves in the future.

@ddurst
Copy link

ddurst commented Dec 5, 2024

At this point, this evolution is but one proposal, and we haven't moved ahead with any plans to changing tokenserver's behavior or role.

@jrconlin
Copy link
Member

jrconlin commented Dec 5, 2024

As a bit of general overview about this...

In The Beginning

When Sync was originally designed, microservices were just starting to become "a thing" and there were starry eyed systems architects that dreamed of being able to let users grant third party access to their data stores using a separate credential system. In addition, we needed sync to run on a horrific number of servers because the back end database couldn't support all of our users and the machines kept dying, so we built some really clever code to divvy users up to a given node, and then remember where they were (up until the machine caught fire, again).

Time marched on, reality set in, and a few hard lessons were learned:

  1. microservices are evil (ok, that's probably more my opinion, but complex systems breed entropy, and microservices make that problem far, far worse)
  2. hand rolling access to data stores is a bad, bad idea. (right, so OAuth2 was just getting started when Sync was built, and folk weren't sure about if it was a good idea or not. Turns out, it was.)
  3. paying for a distributed database was a HELL of a lot cheaper than constantly replacing machines, with an added bonus that since everyone thought of Sync as a backup service (no matter how many times we said it wasn't) we really ought to not lose their data every time a drive exploded.

Work was done and we moved all of the nightmare stuff we had to do to less nightmare-y.

That left a nearly vestigial token server hanging out.

Someday Around Tea Time

So let's look at what token server did vs. what we need it to do.

  • Send users to the right database node - Yeah, no longer a problem. There's only one "node" and it's "spanner". Added bonus, all the folk running their own servers generally only need one "node" as well.
  • Work with credentialed third parties - That never happened, and even if we did something in the future like that, we sure as heck aren't going to use the hand rolled magical crap we came up with 15 years ago.
  • Validate the FxA auth token - Oh, huh, yeah, we still do that, don't we?

So yeah, that's were things are at. Tokenserver does some validation on the "token" the User Agent passes us to indicate that you really are you. That token is created and blessed by FxA (which is the only thing that can say if You are You). We could roll that authentication stuff into the main Sync Server (and we did some leg work already around this) which would kill off the need for a separate machine with it's own database doing some magic.

Goat path to Tomorrow

Mind you, it's not just "us" working here. Remember how I said that FxA are the only ones that can say You are You? We need to work with them to make sure that things work right. FxA is also looking at that 15 year old code and wondering if there's an opportunity to make things a lot easier and better. (If you listen carefully, you can hear the folk working on Thunderbird cheering right now.)

We also have to deal with the UserAgent. Not just the most recent one, but all of the old, in use versions that are out there still. Both for desktop and mobile. That means that we have to come up with an "interim" fix which will probably be "temporary" for 7-10 years, so we're thinking about this pretty darn hard.

The document goes over some plans on all of this. It's not public mostly because in the past when we've brainstormed on stuff some folk took those ideas out of context and started panicking. We've learned to be a bit more close to the vest about that sort of thing and only announce stuff once we actually have a road map. At this point, we have a collection of goat paths and one torn piece of parchment with a bunch of "Here Be Dragons" scrawled on it.

Still, we should be a bit more public about the fact that we're looking at ways to make Syncserver a bit easier and simpler, and hopefully this provides a bit of that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants