CLI Authentication, the Right Way
28 points by ABGEO
28 points by ABGEO
Slopfully worded but interesting. Rotating the device code/link every minute could also mitigate it being used in phishing (and, once it's been used, stopping rotating and locking that session to the IP or browser)
This doesn’t really help as much as the article says it does. It is quite easy to create a phishing landing page that will start the flow when a user navigates to it, and then immediately redirect to the legitimate provider.
The landing page can even provide instructions for providers that force users to provide the code manually (such as Microsoft) and copy the code to the user’s clipboard to make it easier to fall for the phish.
Good write up and agreed that RFC 8628 is the correct solution everything should move towards.
I spend so much time with CLI OAuth dances on a remote dev machine I ended up making a personal tool that papers over the bad UX by shadowing xdg-open and auto-forwarding ports. https://github.com/phinze/bankshot
Interesting. As it happens, I recently implemented the "old" way of authenticating (RFC 8252), and I was unaware of the "new" way (RFC 8268).
But, I think I have a simple explanation for this knowledge gap: my primary use case was to authenticate against Google servers, where the documentation for what I believe to be the RFC 8268 flow explicitly states the following (emphasis mine):
AlternativesIf you are writing an app for a platform such as Android, iOS, macOS, Linux, or Windows (including the Universal Windows Platform), that has access to the browser and full input capabilities, use the OAuth 2.0 flow for mobile and desktop applications. (You should use that flow even if your app is a command-line tool without a graphical interface.)
And that's exactly what I did: I only read up on and implemented the RFC 8252 flow. My tool is indeed a CLI, but since my use case is local-only I wasn't even considering the SSH/containerized scenarios.
Besides, with the RFC 8268 flow, Google constrains you to a limited set of OAuth 2.0 scopes. This could be a deal breaker for some applications.
Minor nit: It's RFC 8628, after I did a double-take on what the original number points to.
On Google's scope constraints, this is OIDC rearing its complicated head. Ideally Google would give you an ID token back instead of munging this into an access token, but that's their OAuth setup and not something intrinsic to 8628.
That's the endless complication around OAuth: the standards are good at defining a framework of how you can build&transport your authorization schemes but deliberately silent on what they should be. It took the invention of OIDC and several years just to get a set of common HTTP endpoints that "most" providers agree on.
I'd much rather default to the browser-based flow because when it works on your local machine, it requires no interaction.
This flow also works for browser based when it works. But has a better fallback for when it fails