Plugin system for extending supported auth methods

[ducaale]

The goal is to allow users to implement custom auth strategies that aren't currently supported. This would also serve as a substitute for HTTPie's auth plugin system.

Related issues that might benefit from this:

1. https://github.com/ducaale/xh/issues/284
2. https://github.com/ducaale/xh/issues/328
3. https://github.com/ducaale/xh/issues/414

I thought about relying on inline shell invocation (--auth-type=bearer --auth=$(get-oauth-token qa)), but that wouldn't work if the auth needs access to the request itself (e.g cURL's --aws-sigv4).

One possible approach is to support:

xh --auth-type=plugin:hmac-sha256 --auth=signature-secret

This would look for an executable like xh-hmac-sha256 (similar to how cargo handles custom commands) and pass it the request details (i.e URL, headers, body, content of --auth). The plugin would output headers to include in the final request.

I would like to hear if this direction makes sense and any other alternatives we should consider.

[ducaale]

Alternatively, once we add support for --unix-socket option, users can have custom forward proxy that handles adding auth headers

xh --unix-socket=/tmp/hmac-sha256 https://httpbingo.org hello=world

[faultymajority]

This makes a lot of sense and HTTP message signatures (RFC 9421) would be amazing to have. That would need access to the request. It would output two or three headers (Signature-Input, Signature, possibly Content-Digest). For the input, a question is whether to pass some textual HTTP/1.1 format, a more structured JSON version, or... what. Ideally reqwest::Request would have some answer to a serde usecase. At least for HTTP signatures, the body isn't needed, as long as a digest algorithm can be selected to get the digest of the request's body.