fxa/docs/adr/0017-switch-settings-auth-to-sessiontoken.md

Switch from OAuth2 to sharing sessionToken with GraphQL server for settings redesign auth

• Status: proposed
• Deciders: Les Orchard, Ben Bangert, Danny Coates, Ryan Kelly
• Date: 2020-05-12

Issue:

• https://github.com/mozilla/fxa/issues/4850
• https://jira.mozilla.com/browse/FXA-1559

Context and Problem Statement

The Settings Redesign app needs to query & mutate the same protected user data as the existing settings app hosted on content-server. This will require some form of authentication & authorization to manage that data.

In ADR-0014, we'd decided to use OAuth2 as the mechanism. But, upon attempting to implement, we discovered that context missing from OAuth2 tokens rendered the option unusable.

Decision Drivers

Basically, same as ADR-0014:

• Smooth UX
• Security
• Development velocity
• Ease of integration

Considered Options

• Reuse existing sessionToken on content-server with auth-server APIs
• Authenticate via OAuth2 to use auth-server APIs

Decision Outcome

Chosen option: "Reuse existing sessionToken on content-server with auth-server APIs", because it's the least novel option requiring fewest changes to auth-server.

Positive Consequences

• Easiest path to authenticating on auth-server for API requests, works almost exactly like the settings client does already.

Negative Consequences

• We defeat the security promises of Hawk, but we're not really relying on them. We'd also like to move away from Hawk in the future anyway.

Pros and Cons of the Options

Reuse existing sessionToken on content-server with auth-server APIs

The Settings Redesign frontend will be hosted at accounts.firefox.com/beta/settings per FXA-1539 / #4819. This means it will have access to the same credentials as the original settings frontend on content-server.

• Pros:
  • Can be done with seamless UX - user visits new settings without confirmation
  • Requires little to no changes on auth-server since the existing sessionToken auth process will be followed.
• Cons:
  • sessionTokens are long lived. Problems if one leaked, though this is unlikely.
  • Passing credentials from client to server defeats the purpose of Hawk.
    • However, this drawback can be considered acceptable because:
      • We don't take advantage of Hawk's security promises
        • Replay protection is ignored
        • FxA is served via HTTPS, so we don't need security over unencrypted HTTP.
      • We'd like to move away from Hawk altogether in the future.

Authenticate via OAuth2 to use auth-server APIs

We would like to someday deprecate the session token mechanism altogether. This could be a start.

• Pros:
  • Security properties of OAuth2 authn / authz are known and not entirely novel
  • Auth-server APIs can be reused with small changes
• Neutral:
  • GraphQL server needs to proxy auth-server APIs
• Cons:
  • APIs on auth-server need auth strategy changes to accept OAuth tokens
  • May initially require a hack similar to payments-server where a pre-generated access token is passed along
  • OAuth2 access token would need reimplementation of many contextual details from sessionToken - i.e. different levels of authentication & verification like ACCOUNT_UNVERIFIED, SESSION_UNVERIFIED, TOTP_REQUIRED that could be implemented in scopes with additional work.