JWT/OIDC Authentication via Vault

1,110 views
Skip to first unread message

Steve Ehleringer

unread,
May 28, 2019, 8:54:35 AM5/28/19
to Vault
Hello everyone,

I'm asking myself right now if vault is capable to authenticate users via JWT without an external OIDC Provider? The documentation (https://www.vaultproject.io/docs/auth/jwt.html) does not say anything about this but the Vault UI suggests that this should be possible by providing a public validation key. Then again, Vault was not able to accept the key I provided. The public key was created with openSSL in the pem format, but Vault still returns the following error message:
error parsing public key: data does not contain any valid RSA or ECDSA public keys

Any help would be appreciated.
Kind regards,
Steve

Steve Ehleringer

unread,
May 29, 2019, 7:25:40 AM5/29/19
to Vault
 Even using the the public key that is used in the tests (https://github.com/hashicorp/vault/blob/170521481d58961761bfd6877221b005cf0f4c7e/command/agent/testing.go) throws an error. See the provided screenshot. Does someone know what I am missing?

Capture.PNG

Kind regards,
Steve

Paul Maddocks

unread,
May 29, 2019, 12:45:54 PM5/29/19
to Vault
As far as I know, you need a provider to authenticate users.
Vault can then authorize their actions based on policies.
I've used azure ad successfully as a provider.

David Adams

unread,
May 29, 2019, 1:16:24 PM5/29/19
to vault...@googlegroups.com
You shouldn't need an OIDC provider to authenticate a JWT, though. I agree it would be great if the JWT auth backend for Vault could provide auth based on whatever JWT claims and key requirements we want to define. OIDC is just one way. But if we have other sources of JWT tokens it'd be nice to be able to use those, too. Hopefully this is mostly a documentation issue.

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.

GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/830b90e3-fd8e-4926-8024-b6e36646deb4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jim Kalafut

unread,
May 29, 2019, 8:59:48 PM5/29/19
to Vault
Hi,

I can reproduce the "error parsing public key" error you're seeing and will review that with the UI devs. In the mean time, you can configure it via the CLI instead:

vault write auth/jwt/config jwt_validation_pubkeys=-<<EOF
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE4+SFvPwOy0miy/FiTT05HnwjpEbS
q+7+1q9BFxAkzjgKnlkXk5qxhzXQvRmS4w9ZsskoTZtuUI+XX7conJhzCQ==
-----END PUBLIC KEY-----
EOF
Success! Data written to: auth/jwt/config

Setting jwt_validation_pubkeys does not require any other external provider (nor is one allowed to be configured). The JWT you submit for auth will be checked against the configured key.

>it would be great if the JWT auth backend for Vault could provide auth based on whatever JWT claims and key requirements we want to define
Can you elaborate? If I'm understanding your question, this is what the bound_claims (https://www.vaultproject.io/docs/auth/jwt.html#bound-claims) parameter is intended to provide.


Regards,
Jim



On Wednesday, May 29, 2019 at 12:16:24 PM UTC-5, David Adams wrote:
You shouldn't need an OIDC provider to authenticate a JWT, though. I agree it would be great if the JWT auth backend for Vault could provide auth based on whatever JWT claims and key requirements we want to define. OIDC is just one way. But if we have other sources of JWT tokens it'd be nice to be able to use those, too. Hopefully this is mostly a documentation issue.

On Wed, May 29, 2019 at 11:45 AM Paul Maddocks <paulma...@gmail.com> wrote:
As far as I know, you need a provider to authenticate users.
Vault can then authorize their actions based on policies.
I've used azure ad successfully as a provider.

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.

GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault...@googlegroups.com.

Steve Ehleringer

unread,
May 31, 2019, 3:14:13 AM5/31/19
to Vault
Thank you for pointing this out and confirming the issue!

Kind regards,
Steve

Steve Ehleringer

unread,
May 31, 2019, 6:04:19 AM5/31/19
to Vault
Small update regarding this issue:

I tried to configure it via CLI as you suggested, but this returned the same error as before:

- directly copying your command

C:\vault>vault write auth/jwt/config jwt_validation_pubkeys=-<<EOF-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE4+SFvPwOy0miy/FiTT05HnwjpEbS
q+7+1q9BFxAkzjgKnlkXk5qxhzXQvRmS4w9ZsskoTZtuUI+XX7conJhzCQ==EOF
<< was unexpected at this time.

- using the syntax as described by the docs (https://www.vaultproject.io/docs/auth/jwt.html)

C:\vault>vault write auth/jwt/config jwt_validation_pubkeys="-----BEGIN PUBLIC KEY-----MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE4+SFvPwOy0miy/FiTT05HnwjpEbSq+7+1q9BFxAkzjgKnlkXk5qxhzXQvRmS4w9ZsskoTZtuUI+XX7conJhzCQ=="
Error writing data to auth/jwt/config: Error making API request.

Code: 400. Errors:

* error parsing public key: data does not contain any valid RSA or ECDSA public keys


Also, I tried to write directly to the config via the HTTP API, returning the same error.

Some information on my Vault setup:
OS: Windows 10 (for testing purposes)
Vault version: 1.1.2

@Jim, may I ask what your setup was, so I can replicate your succession of the write?

David Adams

unread,
May 31, 2019, 11:05:11 AM5/31/19
to vault...@googlegroups.com
I can't tell for sure, but all your examples it looks like some newlines are being removed from what I would expect to see. I also don't see any END PUBLIC KEY lines.

But in any case, I also suspect that Windows cmd.exe may not support multiline argument strings in the same way most unix shells do. You might have better luck putting the public key contents in a file and using the vault cli syntax for loading from the file, eg, put the key into key.pub, and then run:

    vault write auth/jwt/config jwt_validation_pubkeys=@key.pub

key.pub should contain these four lines:

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE4+SFvPwOy0miy/FiTT05HnwjpEbS
q+7+1q9BFxAkzjgKnlkXk5qxhzXQvRmS4w9ZsskoTZtuUI+XX7conJhzCQ==
-----END PUBLIC KEY-----
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/73333d0e-67ba-4d0a-bfe8-362d00b41202%40googlegroups.com.

Vasilev Vjacheslav

unread,
May 31, 2019, 1:13:15 PM5/31/19
to Vault
Hi,

Heredoc syntax is for Linux terminal, not for Windows

Steve Ehleringer

unread,
Jun 3, 2019, 2:09:05 AM6/3/19
to Vault
I actually did it with the END PUBLIC KEY line. I did not pay attention when copying the lines in here. My Apologies for this. Also, just now I tried your suggestion by passing the key via file. Sadly, it resulted in the same issues. I honestly am at the point where I think that it would be better to wait till things are patched and fixed.
Still, I thank you for your help,
Kind regards,
Steve

Steve Ehleringer

unread,
Jun 3, 2019, 2:11:23 AM6/3/19
to Vault
thought so, still gave it a try. I also tried to delete the line breaks, but that didn't help either. And as you can guess, the windows sytax using "^" resultet in the same error.
Kind regards,
Steve

Steve Ehleringer

unread,
Jun 7, 2019, 3:40:56 AM6/7/19
to Vault
Last update in this regard:
It did work on our Linux production environment! Thus, the bug seems to be entirely related to the windows binary
Kind regards,
Steve
Reply all
Reply to author
Forward
0 new messages