зеркало из https://github.com/mozilla/fxa.git
80 строки
3.0 KiB
Markdown
80 строки
3.0 KiB
Markdown
|
# Using Google Auth Library
|
|||
|
|
|
|||
|
|
- Deciders: Vijay Budhram, Wil Clouser, Stéphanie Ouillon, Frida Kiriakos
|
|||
|
|
- Date: 2022-02-03
|
|||
|
|
|
|||
|
|
## Context and Problem Statement
|
|||
|
|
|
|||
|
|
To help improve Firefox account adoption we want to give users flexibility when it comes to signing up for an account.
|
|||
|
|
To do this we plan on adding support for a limited number of clients that will allow them to create a Firefox account from a Google account.
|
|||
|
|
|
|||
|
|
This ADR covers the options we looked at to integrate with Google Auth.
|
|||
|
|
|
|||
|
|
## Decision Drivers
|
|||
|
|
|
|||
|
|
- Future maintenance
|
|||
|
|
- Ease of integration
|
|||
|
|
- User experience
|
|||
|
|
- Security implications
|
|||
|
|
|
|||
|
|
## Considered Options
|
|||
|
|
|
|||
|
|
To add support for Google authentication we have a couple of options
|
|||
|
|
|
|||
|
|
1. Load Google’s [Identity Services framework](https://accounts.google.com/gsi/client) directly on FxA domain to implement the authentication
|
|||
|
|
2. Load Google’s [Identity Services framework](https://accounts.google.com/gsi/client) on a subdomain of FxA
|
|||
|
|
3. Implement Google Oauth2 authorization code flow (does not require 3rd party library)
|
|||
|
|
|
|||
|
|
## Decision Outcome
|
|||
|
|
|
|||
|
|
At this current time we decided to go with Option 3 (Implement Google Oauth2 authorization code flow).
|
|||
|
|
|
|||
|
|
While Option 2 seems like the best compromise between user experience and security, it is more complex and could potentially introduce more bugs. In the future, we can try to prototype this approach.
|
|||
|
|
|
|||
|
|
## Pros and Cons of Options
|
|||
|
|
|
|||
|
|
### Load Google’s Identity Services framework directly on FxA domain
|
|||
|
|
|
|||
|
|
Pros:
|
|||
|
|
|
|||
|
|
- Very easy to implement
|
|||
|
|
- Google will be deprecating [older framework](https://developers.googleblog.com/2021/08/gsi-jsweb-deprecation.html) to support this
|
|||
|
|
- Library has several new features such as one-tap signin that greatly reduce friction for creating an account
|
|||
|
|
|
|||
|
|
Cons:
|
|||
|
|
|
|||
|
|
- Can not audit library
|
|||
|
|
- No versioning (we can not see when changes occur)
|
|||
|
|
- No official or clear channel of communication for any updates
|
|||
|
|
- Little visibility on what is going on in the code
|
|||
|
|
- If an attacker exploits a vulnerability in the lib to abuse the flow they might be able to login into an account
|
|||
|
|
|
|||
|
|
### Load Google’s Identity Services framework on a subdomain of FxA
|
|||
|
|
|
|||
|
|
Pros:
|
|||
|
|
|
|||
|
|
- Reduces risk of account being abused since library is loaded on a different domain
|
|||
|
|
- Library has several new features such as one-tap signin that greatly reduce friction for creating an account
|
|||
|
|
|
|||
|
|
Cons:
|
|||
|
|
|
|||
|
|
- Requires shuffling around our `email-first` page which could be complex and introduce bugs in our code and metrics
|
|||
|
|
- Can not audit library
|
|||
|
|
- No versioning (we can not see when changes occur)
|
|||
|
|
- No official or clear channel of communication for any updates
|
|||
|
|
- Little visibility on what is going on in the code
|
|||
|
|
|
|||
|
|
### Implement Google OAuth2 authorization code flow
|
|||
|
|
|
|||
|
|
Pros:
|
|||
|
|
|
|||
|
|
- We don't load any third party javascript
|
|||
|
|
- Google uses oauth and openid standards so the implementation is straightforward
|
|||
|
|
- We can audit our code and push fixes as needed
|
|||
|
|
- User experience would be the same as Pocket Google Auth flow
|
|||
|
|
|
|||
|
|
Cons:
|
|||
|
|
|
|||
|
|
- Would not have one-tap signin and user experience would not be as good as using the Google library
|
|||
|
|
- We can introduce bugs into our code
|