> On an IOT device, or a retrocomputing/hobbyist platform, you'd likely want to display a QR code and have the user authenticate with their phone, similar to how you log into Netflix on a smart TV.
It's a fair point, and there are specs[0] defined for these uses. Something like rclone could certainly do it this way if Google supports it on their end. But IMO the UX of browser-redirect OAuth is actually pretty dang good. I would like to have that available for CLI apps. What if you could literally import an ncurses library directly into your app and do the flow in-process? I'm not even sure if there's a way to do that securely but it would be sweet.
> As an aside, to my knowledge OAuth2 still works in PaleMoon.
That's going to depend completely on the OAuth2 implementation on the authorization server. It's completely up to the provider whether to require JavaScript or other features in order to render their consent page. Having a stronger specification of how to build those pages would offer more guarantees for interoperability.
> What if you could literally import an ncurses library directly into your app and do the flow in-process? I'm not even sure if there's a way to do that securely but it would be sweet.
I mean, the security of OAuth as a UX flow is that you're entering your username and password on the site you're authenticating with, not the intermediary. (And this is verifiable by looking at the address bar, insofar as that's a reliable option.)
I recall using an Electron app that did OAuth using its own web view, and despite being a fairly well-known app, I had some misgivings because I had no way of knowing if that Google login interface was actually Google's OAuth page or a mock-up generated by the app. (Not trying to spare the guilty here, I can't remember which app. Too many suspects.)
I don't see how you could avoid this problem with an imported ncurses library. Even if the requesting process launched a separate trusted binary to do the authentication flow, verifying that you were actually interacting with that program instead of a mockup is very far into the weeds of tech savvy, and at best is even slower than doing the process manually.
The only option I can see working is to have a dedicated OAuth app. You copy-paste some sort of request token out of the client, it prompts you for username and password, then it gives you a code to enter into the client. Basically the same as a how CLI apps negotiate OAuth now, except you never leave the terminal.
Not saying it's a better idea, just that it's the only one.
It's a fair point, and there are specs[0] defined for these uses. Something like rclone could certainly do it this way if Google supports it on their end. But IMO the UX of browser-redirect OAuth is actually pretty dang good. I would like to have that available for CLI apps. What if you could literally import an ncurses library directly into your app and do the flow in-process? I'm not even sure if there's a way to do that securely but it would be sweet.
> As an aside, to my knowledge OAuth2 still works in PaleMoon.
That's going to depend completely on the OAuth2 implementation on the authorization server. It's completely up to the provider whether to require JavaScript or other features in order to render their consent page. Having a stronger specification of how to build those pages would offer more guarantees for interoperability.
[0]: https://datatracker.ietf.org/doc/html/rfc8628