On Fri, 19 Oct 2018 at 08:33, Nicholas Alexander <nalexan...@mozilla.com> wrote:
> > On Thu, Oct 18, 2018 at 1:33 PM Vlad Filippov <vfilip...@mozilla.com> > wrote: > >> Hi all, >> >> We are in the process of merging the oauth-server into auth-server[1]. >> This has been a proposal for several years now. The best time to do this >> was years ago, the second best time is now. >> > > Can we get some discussion of why we didn't build oauth support into > `fxa-auth-server` to begin with? I recall there was a desire to isolate > potentially security sensitive code (much of which is centralized in the > customs server now?). > Thank you for an excellent question! I'm sure I don't remember all the reasons, but I recall the OAuth support starting out as a kind of "side project", a way to help website developers who wanted to stick with a more familiar OAuth flow rather than deal with BrowserID. We're now in a place where OAuth is the preferred method of integration, and BrowserID is legacy cruft. I think we suffer quite a bit of architectural weirdness because of this and I've been working on articulating that story in full. The doc is very draft, but may provide some insight on what's motivating this: https://docs.google.com/document/d/1gOmR5cV9Tnl92Ia2KBzUF3AUYqUALlKenu2bG_0WrBI/ Merging the two servers together does indeed increase the code and API surface that's in the same process as highly-sensitive account data such as the user's password, but the risk seems acceptable to me. The oauth-server codebase is actually pretty small and its API surface pretty simple. It's the auth-server that handles a lot of complex things like email sending. So I don't expect the incremental complexity to increase by that much. It's also true that the boundary between auth-server and oauth-server has been slowly blurring for a while now. We have routes in the auth-server that accept OAuth tokens for authorization. We have code in the auth-server to query the oauth-server to look up the metadata about a given client_id. And we've been adding more and more custom fields in auth-server BrowserID assertions just for the purposes of tunneling that data over to the oauth-server. So it's entirely possible that overall complexity will *decrease* if we manage to merge the two together :-/ There probably is an architecture that splits these into microservices where the highly-sensitive data and code is nicely isolated from the broader system, but the current one ain't it. I expect it would look more an "fxa-password-db" microservice that just does the password-checking stuff. Why are the reasons we made a decision years ago no longer appropriate? > With the benefit of hindsight and several years worth of experience supporting different reliers, it seems clear that some of our microservice boundaries were originally drawn in the wrong place. Our approach has basically been to wait until we're feeling sufficient pain, then smoosh the microservices back into a monolith, then refactor until it becomes more obvious what the boundary should be. We've had good success with this recently with our email-sending infrastructure. It originally started out as an fxa-auth-mailer microservice, which over time was found to be too tightly coupled to fxa-auth-server and so was smooshed back in. We're now in the final stages of extracting a *different* email-sending microservice with looser coupling. Hope that helps, Ryan
_______________________________________________ Dev-fxacct mailing list Dev-fxacct@mozilla.org https://mail.mozilla.org/listinfo/dev-fxacct
