Add device flow after code flow callbacks direct to vault

[DrDaveD]

Overview

This adds support for OIDC device flow on top of pr #130 as an alternative to the implementation in pr #122. #130 has to be committed first and all its changes are included here. If you'd like to see just the changes compared to that pr, see my own pr 1.

Device flow has several advantages over direct callback mode:

1. There's no need to configure allowed redirect uris for the client.
2. There's no need to configure firewalls to allow the Authorization Server to call back to Vault.
3. There's no need for the Authorization Server to recognize the CA cert for Vault.
4. The URL that the user sees is simpler.

So it's worth having device flow even with direct callback mode, although direct callback mode is good when Authorization Servers don't support device flow.

Design of Change

Device flow is enabled with this implementation by setting the role configuration callback_mode=device. The device authorization endpoint is auto-discovered. This also adds an additional optional role configuration option poll_interval which defaults to 5.

The client API is slightly extended, to add an optional user_code option in the auth response, and to add a slow_down reply to a poll request. A redirect_uri passed in to the auth API is ignored in device flow.

Related Issues/Pull Requests

#103, #122 and #130

Test results

ok  	github.com/hashicorp/vault-plugin-auth-jwt	4.932s

Contributor Checklist

[ ] Add relevant docs to upstream Vault repository, or sufficient reasoning why docs won’t be added yet
Will do if the PR is acceptable
[x] Add output for any tests not ran in CI to the PR description (eg, acceptance tests)
[x] Backwards compatible

[DrDaveD]

Updated for version 0.9.2

[DrDaveD]

Updated for version 0.9.4

[DrDaveD]

Force-pushed to be a single commit after direct callback mode, and updating to the master branch at the time of the 0.10.1 tag.

[DrDaveD]

Force pushed after updating for 0.11.1

[hashicorp-cla]

All committers have signed the CLA.

[DrDaveD]

Force-pushed after updating for 0.12.1

[sepiroth887]

Really excited for this PR to merge. What's the path here to completion and inclusion in vault (or is it directly usable as a plugin as well?)

[DrDaveD]

I do use it as a plugin to vault for now. I include it in an rpm that I build based on my htvault-config package. It ends up forking a process for every issuer so it would be better if it were included internally.

[DrDaveD]

Updated after #204 merged into main

[jmls]

is this pr ever going to make it in ? Would really like to see it

[DrDaveD]

Rebased on main after the commits of October 12, 2022

[DrDaveD]

I just did another force push to add support for "verification_url" in addition to "verifcation_uri", since some older server implementations such as Google use the former despite what's in the RFC.

[tmaroschik]

Thanks @DrDaveD for keeping this up to date. Hopefully it goes in at some point finally...

[Zlaticanin]

@DrDaveD Thank you for submitting this. We’re discussing it internally and will keep you updated.

[42wim]

@DrDaveD I've tested the PR and both flows and it works fine 👍

Some thoughts:

I think it would be also useful if there's an option for a manual flow too, like in #125

This makes it a bit more secure for possible phishing attacks where an attacker can generate an URL, get a user to click on it (which may be automatically executed because of SSO) and the attacker then can get the token. Of course this makes it less userfriendly. I've hoped the device flow would've solved that, but keycloak for example will return an URL with the code in, so this also can be done automatically with the device flow.

And/or exposing the oidcRequestTimeout so that this can be brought down to seconds in direct mode instead of 10 minutes. (should probably be also have another cache that doesn't allow repopulating with the same clientnonce and escape the cleanup)

[DrDaveD]

And/or exposing the oidcRequestTimeout so that this can be brought down to seconds in direct mode instead of 10 minutes. (should probably be also have another cache that doesn't allow repopulating with the same clientnonce and escape the cleanup)

This option sounds more useful to me than manual mode.

[tsipinakis]

Any updates to this PR? Having to port forward a local HTTP server to finalize the auth has been a huge pain for our vault deployment.

[DrDaveD]

I have been keeping it up to date, but the maintainers haven't moved on it in 4 years. The corresponding PR this depends on has now been merged into the openbao development branch and the developers there plan to include the PR corresponding to this one soon.

[tsipinakis]

Thanks for the heads up @DrDaveD . We'll evaluate OpenBao as an alternative, seems like it's moving faster.