Add oidc device flow after direct flow #319
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds support for OIDC device flow on top of pr #318. #318 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:
So it's worth having device flow even compared to direct callback mode, although direct callback mode is good when Authorization Servers don't support device flow.
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 optionpoll_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 aslow_down
reply to a poll request. Aredirect_uri
passed in to the auth API is ignored in device flow.This is essentially the same PR as hashicorp/vault-plugin-auth-jwt#131 which many people have expressed an interest in but has been sitting unmerged for a few years.