Introduce manual mode for OIDC client authentication for systems without displays

[broamski]

Overview

This attempts to solve the problem of authenticating to Vault via the OIDC Auth method on systems that do not have a display and/or a browser available. e.g. You wish to obtain a vault token (via OIDC Auth) on a system that you are ssh'd into. Without this capability, users often resort to distributing a single workstation token to several external systems.

Design of Change

Adds a new mode parameter to the OIDC vault login command. If omitted, the default value (browser) retains the existing workflow. By default, the existing user workflow will not be changed. Supplying mode=manual initiates the login process in manual mode.

When manual mode is triggered, the user's browser is no longer automatically launched to the supplied authentication URL. Instead, the user is able to copy the URL from the display and supply it to a browser of their choice. Upon successful authentication, instead of being redirected to the client's local http server callback url (as this is not possible, because the downstream system and the users workstation are disparate), the request is redirected to the Vault server itself at the path <mount>/oidc/manual (e.g. https://vault.server.company:8200/v1/oidc/oidc/manaul). The oidc/manual handler receives 2 fields, code and state, which are concatenated via a | character, base64 encoded, and presented for the user to copy and paste into the client, which is awaiting input.

In manual mode, instead of the client running a local HTTP server listening for the response, the client accepts the code displayed in the step above via stdin. Once received, the client decodes the value, splits it, and continues the authentication process by calling oidc/callback, identical to the callbackHandler. From this point, the process remains unchanged.

$ vault login -method=oidc mode=manual
Complete the login via your OIDC provider by following this link in your browser: 

    https://yourfriendlyauthserver.com/oauth2/v1/authorize?client_id=XXXXXXXX&nonce=XXXXXXX&redirect_uri=http%3A%2F%2Flocalhost%3A8200%2Fv1%2Fauth%2Foidc%2Foidc%2Fmanual&response_type=code&scope=openid+openid+profile+groups&state=XXXXXX


Enter verification code: 

Contributor Checklist

• docs PR Link
• Backwards compatible

[kalafut]

Thanks for the PR! I've not looked at it yet, but conceptually how does this compare to Device Flow logins (e.g. #122)?

[broamski]

Hi @kalafut! Fundamentally it's similar, but I'd say the main difference here is because not every provider support the Device Flow, this PR should cover more use cases as it's fully self-contained.

[kalafut]

Thanks. We'll be reviewing this (both code and general fit) during this current release cycle.

[DrDaveD]

@broamski If there's a redirect URI to accept the response on the vault server itself, why does the user still need to enter a code? Couldn't that all stay within vault? I never really understood why the web server was on the vault cli client. The callback API would have to change of course, but maybe it could be more like the device flow callback in #122 and just wait until the OIDC provider responded back.

[DrDaveD]

It seems to me that the two features of (a) not launching the browser and (b) calling back to the vault server instead of the vault cli client are two independent things that people might want, and it would be better to not tie them together.

[kalafut]

I never really understood why the web server was on the vault cli client.

If you're doing a CLI login, the vault CLI process needs to end up with the token in the end. If the browser redirected directly to Vault, the browser would receive the token instead the vault login command.

[DrDaveD]

If you're doing a CLI login, the vault CLI process needs to end up with the token in the end. If the browser redirected directly to Vault, the browser would receive the token instead the vault login command.

I don't see why the browser would get it; connecting to a web server in the vault CLI process isn't fundamentally different from the Vault server. Do you mean the Vault server would get it? If the Vault server gets it, why can't it pass the token back to the vault CLI via the second API call like the device flow does?

[DrDaveD]

I am working on a new PR that will enable the code flow to direct its response to Vault without requiring user intervention. I'm pretty far along and don't see a show-stopper yet. I expect it to be significantly simpler than #122, more generally applicable because it doesn't require the Authorization Server to support the device flow, and more user-friendly than this PR because it doesn't require copy/pasting the code & state string. I hope to have it ready for review by the end of next week.

[DrDaveD]

See #130

[DrDaveD]

@broamski Can you please test if #130 meets this need? Isn't it better to not require the user to have to copy the state & code? It doesn't avoid attempting to launch the user's browser, but I don't see what harm there is in the attempt.

[hashicorp-cla]

All committers have signed the CLA.

[broamski]

It's clear to me that after 2+ years, this PR is not going to be accepted. I ended up writing my own authentication plugin in lieu of using the built-in jwt plugin.

[DrDaveD]

@broamski Is your plugin available on github? If so please provide a link.