🏗️ Convert Token Server to Rust (meta)

[jrconlin]

The token server should be ported to rust. This issue will encapsulate the requirements and act as a cornerstone for that effort.

In addition, the token server will probably be rolled into an existing service like syncstorage-rs, so it's important to isolate functions and interfaces so that they can be brought in as seamlessly as possible.

Note: while mozilla production will switch to using spanner as it's backend, there are a host of providers that will continue to need SQL database support. The current database system they're using is MySQL.

To aid in that effort the following structures will be required:

• rust stable (not nightly) with async/await support
• meet or exceed foxsec baseline criteria:
  • failure error handling
  • slog / moz-slog error reporting
  • pass cargo format and cargo clippy without warnings or errors
• Actix-web 2.0+ webserver framework
• diesel database framework

various core elements required are:

• [ ] Assignment: provide a means to persistently assign users to a valid node (allowing for node removal or rebalancing)
• [ ] BrowserID verification: provide auth token validation for BrowserID
• [ ] OAuth verification: provide auth token validation for OAuth - https://github.com/mozilla-services/tokenserver-rs/issues/4
• [ ] Dockerflow: provide dockerflow endpoints
• [ ] Data storage for
  • [ ] Memory
  • [ ] SQL storage
• [ ] Misc. support functions including:
  • [ ] email hashing
  • [ ] fxa_metric hashing
  • [ ] timestamp normalization (to milisecond)
  • [ ] fxa_keyid generation and parsing
  • [ ] any updates needed related to the concurrent CWTS project that will require changes in legacy tokenserver.

As well as the general functions required for the stand alone system

• [ ] JWT parser/compiler
• [ ] logging (using slog)
• [ ] metrics (using cadence)
• [ ] settings parser and management
• [ ] error handling (using failure)

All components need to pass appropriate unit and interactive testing.

[tublitzed]

Just to clarify on requirements here related to BrowserID specifically; @rfk do you forsee us needing to keep it around for support purposes for longer than say...the summer? We likely won't land this one for some time, so looking to avoid implementing something that we may not need here.

[rfk]

related to BrowserID specifically; @rfk do you forsee us needing to keep it around for support purposes for longer than say...the summer?

Realistically, yes. We're going to have to wait for at least Firefox 68 ESR to age out, and possibly also Firefox 78 ESR, before we can disable BrowserID entirely.