Add oidc callback mode that is direct to server

[DrDaveD]

This adds a new option to the oidc auth method role option called callback_mode. When set to direct it enables the callback from the Authorization Server to be direct to bao instead of to the client. This allows clients from multiple users to share a machine because they do not need to share a port to listen on, and it also makes for easier management of firewalls, etc, because only the bao server needs to be configured to accept connections from the Authorization Server instead of every client.

When callback_mode=direct is set, the oidc/auth_url client API returns additional parameters 'state' and 'poll_interval'. The client is then expected to call a new API oidc/poll (instead of oidc/callback) and try again every poll_interval seconds while the response is an http 400 error authorization_pending. When the Authorization Server instead calls the oidc/callback api, the response is in html because it goes to the user's web browser, and the authorization information is stored in the state entry until the next call to oidc/poll.

The cli also has a new option callbackmode=direct (without an underscore) to apply different defaults for the redirect_uri parameter, based on the $VAULT_ADDR environment variable. That is a convenience and is not strictly necessary in order to make it work. When there is a state in the response to the oidc/auth_url API, instead of starting a listener the client calls back to oidc/poll every poll_interval seconds.

cli_responses.go is renamed to html_responses.go because it's not used exclusively for cli (and in fact it already wasn't).

Essentially the same PR has been pending in hashicorp/vault-plugin-auth-jwt#130 for several years, and although several other people expressed an interest in it, no action has been taken to merge it yet there. It has been in production use for a couple of years through https://github.com/fermitools/htvault-config.

[cipherboy]

Thanks for this, it is looking fairly comprehensive @DrDaveD! One thing missing that I see off the top of my head are doc updates?

[DrDaveD]

Thanks for all the detailed comments. This is just to tell you that I won't be able to look at them closely this week, but should be able to the following week.

[DrDaveD]

I was waiting to write the docs until I had interest shown that the PR would be accepted. I have updated the docs now but am waiting to commit until I do some more testing.

[DrDaveD]

I decided to go ahead and push it as-is but mark the PR as draft for now until I am able to do further testing

[DrDaveD]

I fixed the crash that I mentioned in the status meeting yesterday; it was in the code of this PR. This is now ready for re-review.

[cipherboy]

This looks good, thank @DrDaveD! I'd probably wait until after Beta to merge this though.

[cipherboy]

@DrDaveD Do you mind rebasing this? I have consensus to merge ahead of GA from Dan &co, but I think test-go (10) was failing due to an earlier fix we've merged. Thanks!

[DrDaveD]

@cipherboy it is rebased. The "Vulnerable dependencies" CI failure do not look to be related.

[cipherboy]

Ah, one last thing -- mind if I bother you to do GPG/SSH signing of commits? Dan was in favor of leaving that enabled on our last community call so for now we'll enforce it, but going forward we might think about changing the requirements if you have thoughts either way. :-)

Thanks and sorry!

[DrDaveD]

@cipherboy It looks like I managed to figure out how to automate it using ssh. However there are more CI tests failing that are unrelated.

[cipherboy]

Perfect, thanks @DrDaveD! And apologies, we opted on the last community call to stabilize the release and wait on pending PRs; I've merged this for the next release (which I'm tentatively calling v2.1.0 but we'll see what the community decides tomorrow).