Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add a buf login browser-based auth flow #753

Open
lrewega opened this issue Dec 1, 2021 · 1 comment
Open

Add a buf login browser-based auth flow #753

lrewega opened this issue Dec 1, 2021 · 1 comment
Assignees
@emcfarlane
Labels
Feature New feature or request

Comments

@lrewega
Copy link
Member

lrewega commented Dec 1, 2021

I think there is an opportunity to provide a better login experience that removes the need for a user to generate a token and paste it into their terminal. For example:

  • buf login [<remote>] opens the user's browser to a page on the remote BSR similar to the current create-a-token page, but specific to this flow.
  • The user logs in via SSO with their IdP if necessary -- valid existing sessions are respected.
  • The user is presented with a "Approve authenticating the buf CLI" dialog, presses "Approve".
  • A short-lived machine token is minted (~24 hours; configurable).
  • buf login receives the machine token from the BSR1 and persists it to the user's .netrc.

Note that in this flow, the CLI and IdP do not interact at all. There are several assumptions baked into this about what sort of secrets/sessions are shared between the CLI and BSR -- I have several ideas -- but I am more interested in what folks think about this concept.

There would also have to be some way to fallback the current approach e.g. --[no-]launch-browser, etc.

Footnotes

  1. there is an implicit assumption in this design that the CLI first performs some sort of handshake or establishes some other relationship with the BSR such that it can wait around for the token to be minted or not2. Some sort of identifier must be included in the URL sent to the browser so the BSR can correlate the CLI and browser sessions3. ↩

  2. in the case where a token was not minted, either the CLI can wait for the NACK from the BSR or can time out if the URL+identifier wasn't accessed in some short amount of time (O(seconds)) ↩

  3. because avoiding state is desirable, we could transmit some sort of magic-wormhole-like pre-shared-key such that no new state would be necessary from the perspective of the BSR. ↩
@lrewega lrewega added the Feature New feature or request label Dec 1, 2021
@amckinney
Copy link
Contributor

For reference, there's some prior art that acts very similar to what you're describing in https://github.com/bufbuild/core/pull/399.

@amckinney amckinney added the P2 label Dec 7, 2021
@bufdev bufdev removed the P2 label Feb 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@emcfarlane emcfarlane

Labels
Feature New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@lrewega @emcfarlane @bufdev @amckinney