chore(docs): Add ADR for Google Auth Library approach

This commit is contained in:
Vijay Budhram 2022-02-03 12:33:46 -05:00
Родитель abdf238762
Коммит dcf9ff1286
Не найден ключ, соответствующий данной подписи
Идентификатор ключа GPG: EBAEC5D86596C9EE
1 изменённых файлов: 79 добавлений и 0 удалений

Просмотреть файл

@ -0,0 +1,79 @@
# 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 Googles [Identity Services framework](https://accounts.google.com/gsi/client) directly on FxA domain to implement the authentication
2. Load Googles [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 Googles 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 Googles 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