Using Hashicorp Vault for storage of client id and secret that is passed to backend for OAuth2

[John Stafford]

I am new to Hashicorp Vault. I was hoping to secure my client id and secret for an OAuth2 Password Flow using Hashicorp Vault. Each time my backend REST API is called, it requires the application client id and secret. How would I do this in a secure way and only let my app pass this without disclosing this in my javascript client? Thanks. John

[John Stafford]

So I have a javascript client that calls a Spring Vault backend. I know how to use Vault for my Spring backend, but for my client id and secret that I pass from my frontend javascript client, can I incorporate a Vault Javascript client that works off the same mysql database that I am using for my Spring Vault? Which Vault client do you recommend to run in concert wtih my javascript client?

[John Stafford]

last question, how does exposing my root token on my javascript client work ? Seems like a security concern.

[John Stafford]

Merry Christmas!

[Jeff Mitchell]

Hi John,

To be honest I'm not totally clear on what you're trying to accomplish
but I think what you are asking is, you have JS that is sent to client
browsers, and you want that JS to retrieve credentials from Vault that
it can then send to your REST API. But you are concerned about having
a secret hard-coded into your JS.

There's good news and bad news on that front. Bad news first: to make
that Vault call you'd need a Vault token, so at a first order what
you've done is merely shift the burden of protecting a secret in the
client JS to Vault instead of to the original OAuth credentials. This
is basically the question of how do you secure session tokens/cookies,
and the answer is, you can secure them from other sites but not really
from the authenticated client.

You say that you have an app in the middle between your backend API
and your JS, so if this is the case, one immediate possibility is for
the app to issue its own session tokens. The JS uses its session token
to call the app's API, which then uses its Vault-stored credentials
against the backend REST API.

If it's direct client-JS-to-REST-API, things are different. And I do
want to say that up front, in a sort of overarching sense, there isn't
a big difference between the user's browser and the user herself
making API calls with the client-JS-stored credentials. So you may
want to think about whether removing the underlying OAuth credentials
from the JS is actually necessary -- or more likely you may want to
think about whether instead you should be storing those credentials in
browser secure storage to be referenced from JS rather than embedding
in the JS itself.

However, if embedding is the only way, one thing you may want to think
about is using the transit backend with key derivation (context). This
way you can send the context and encrypted credentials in the JS along
with a Vault token; the JS can then use the Vault
token/context/encrypted credentials to fetch the decrypted credentials
in-memory and then use that to make a call.

This has a few advantages. One is that decrypted credentials are never
stored on disk (e.g. in browser cache). It also means that you can
revoke the Vault token and stop the client JS from being able to
retrieve the decrypted credentials...of course, keeping in mind that
if the user decides to modify the JS they can easily run the code and
store it locally, so it should still be credentials that should be
scoped narrowly enough that if the user discovers them it's not an
issue. By using key derivation, if the user manages to get someone
else's encrypted credentials they can't decrypt them unless they also
get the context value (likely in this scenario, but defense-in-depth).
Finally, it's easier to manage ACLs around transit than it is to store
these values in Vault's KV store and manage per-user policies to
control access to specific value to specific users.

Hope that helps!

Best,
Jeff

> --
> 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/186899c4-804b-481c-847d-f6bfb679485a%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[John Stafford]

Thanks for the reply Jeff! Sorry for not replying sooner.

My problem lies in using the wrong OAuth2 flow for a JavaScript client. I was using the password flow which requires a secure client to maintain a client secret. The implicit flow is what I need and it is designed for pure JavaScript client, and requires no need for secret on client side. So, this scenario I described doesn't and shouldn't exist anymore.