On May 5, 2014, at 3:26 AM, a. <[email protected]> wrote: > > As Ryan suggested, I am posting my feature request/idea on here for > further discussion. > > So I am currently running my own sync storage server. Thanks to recent > commits, the sync server now has a "allow_new_users" config option, > which restricts new user signup. While sufficient from a "just works" > perspective, it has the issue that unwanted requests to the storage > server push completely through to the server and only get rejected when > no already active token is found in the database. >
Hi, thanks for your email! I think there's a little misconception here - there is no database of active tokens. The sync server takes a presented token and sees if it has an unexpired timestamp and a valid signature. If it doesn't, it rejects the request and asks the user to return to the tokenserver to get another one. This is about as low-touch an auth solution as possible - no lookups required. Adding more authentication won't actually buy you anything and would make the lookup substantially heavier. The token itself comes from the token server. That also doesn't do an auth lookup - it uses the cert provided by the browser. Whether that cert is issued by the Mozilla FxA server or your own auth server is irrelevant to the tokenserver (delta configurations that restrict this, of course), The allow_new_users config option doesn't prevent registrations if it's off, it just prevents users that haven't historically had an assignment in your install from being allocated to a node, making getting a token impossible. As you can see, it means that getting your own auth server doesn't actually affect the security of the rest of the system - the pieces are designed to work independently. You should want your own auth server if you want to control everything end to end, or don't want to share any of your information with Mozilla. (This doesn't invalidate the rest of your request, which is something we'd like, but is very, very substantial work, but I wanted to ease your concerns over the technical/security questions here) Toby _______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
