JanitorTechnology
Wishlist: Sign in with
At the moment, users can sign in by clicking a link sent by email. Here are other ways a user might want to use in order to sign in. As @jankeromnes pointed out, the list should be split. The first list is for sign-in only methods:
- [ ] Sign in with a Time-based One-Time Password (using an authenticator app) ( RFC6238, speakeasy: node implementation )
The second list is for signing in with/authorising other services and automating some features in interaction with these external services:
- [ ] Sign in with GitHub
- [ ] Sign in with Phabricator
Great idea! Thanks a lot for opening this issue.
I believe there is another component to this: signing in with GitHub can let users grant OAuth tokens to Janitor, authorising us to use various API scopes on their behalf (could be useful to automatically configure preferred committer name and email in containers, pre-authorize all the user's public SSH keys, etc). So this could also be a "service links" or "authorized services" section in the settings page.
In that same spirit, I'd like us to add a "sign in with bugzilla" feature (or just "authorize bugzilla" / "link bugzilla account"), which will allow Janitor to request a Bugzilla API token that can be copied into Firefox developers' containers, allowing them to easily upload patches for code review.
Note: The aforementioned "service links" are now called "Integrations", and will live in /settings/integrations/ (as soon as the recently merged pull request is deployed, which I expect to happen this week). This issue can serve as a wishlist for both "Sign in with" services, and third-party service "Integrations".
Note: I've renamed "Sign in with Bugzilla" to "Sign in with Phabricator".
With these "integrations", our goal is to pre-configure Janitor containers so that developers can send commits to code review in just a few clicks. We have several options to achieve this:
GitHub
- OAuth app: Users sign in with GitHub, and grant Janitor a few OAuth scopes. To send pull requests, we'd need the
public_reposcope ("Grants read/write access to [...] public repositories and organizations"). However,public_repois a powerful scope, which would make our OAuth tokens dangerous in case they're stolen. - GitHub App (previously "GitHub Integration"): These need to be hosted somewhere and installed per-repository. They offer narrow, specific permissions, so we have a better chance of restricting it to only open pull requests (not merge arbitrary code), but they also seem a lot more complicated to create.
- "Janitor bot" user: We could create a GitHub user called "Janitor bot", and use it to create pull requests on behalf of our users. It wouldn't have access to any "real" repositories, but essentially anyone could hack its forks and pull requests.
| Integration type | Send to code review | Any public repository | See private things | Merge any code | Hack other code reviews |
|---|---|---|---|---|---|
OAuth public_repo app |
✔️ | ✔️ | ✖️ | ⚠️ | ✖️ |
| GitHub app | ✔️ | ❌ | ✖️ | ✖️ | ? |
| "bot" user | ✔️ | ✔️ | ✖️ | ✖️ | ⚠️ |
Phabricator
- OAuth app: Maybe we can allow Janitor users to "Sign in with Phabricator", and then grant some OAuth scopes to Janitor. But I don't know if we can register OAuth apps in Phabricator.
- "Janitor bot" user: We could create a Phabricator user called "Janitor bot", and use it to upload commits for code review on behalf of our users. It wouldn't have access to private bugs, but essentially anyone could hack its code reviews.
A side note for this: Keycloak is a powerful authentication server which will provide OAuth, TOTP and normal email-password flow as well as enterprise authentication like SAML. Using that may allow us to reduce the boilerplate.
So, I'm feeling like the best way to do this is to use an external OpenID connect provider, like Keycloak (OSS) or Auth0 (used in Mozilla). As they can be used with only standardized flows, there's no risk of lock-in and we no longer have to reinvent the wheel.
