search

ducaale / xh

Friendly and fast tool for sending HTTP requests
MIT License
5.64k stars 98 forks source link

Add support for OAuth 2.0 authentication flows #284

Open jirutka opened 2 years ago

jirutka commented 2 years ago

Can you please consider adding support for OAuth 2.0, at least the client_credentials grant?

Example:

xh --auth-type oauth2 --auth <client_id>:<client_secret> --oauth-grant client_credentials --oauth-token-url https://example.org/oauth/token GET example.org/api/v1/hello
ducaale commented 2 years ago

@jirutka Given that we don't support plugins yet, I think we could add auth types that people find useful. Do you know of any CLI tool that supports OAuth 2.0? I know there are a couple of OAuth HTTPie plugins, but they differ from your proposed implementation.

jirutka commented 2 years ago

I don’t know about any, that’s basically the reason why I’d like to add it into xh.

blyxxyz commented 2 years ago

In general we try to be compatible with HTTPie.

Similar issue for HTTPie (currently empty): httpie/httpie#1427

For reference, this OAuth 1.0 plugin exists (and is listed in the official docs): https://github.com/qcif/httpie-oauth1

While it's ugly I think we'd want to go for the same approach of cramming everything inside the --auth option. That doesn't bloat the options and makes it much easier to persist in session files.

A popular OAuth 2.0 crate exists: https://lib.rs/crates/yup-oauth2

jirutka commented 2 years ago

While it's ugly I think we'd want to go for the same approach of cramming everything inside the --auth option.

It was just an example, I don’t insist on that choice of options at all. :)

A popular OAuth 2.0 crate exists: https://lib.rs/crates/yup-oauth2

This is not suitable, it provides just the ‘device’, ‘service account’ and ‘installed’ authorization flows, not client_credentials nor authorization_code.