Vault as OIDC Provider Access Token Issue

[nisarg.bhatt]

Hello,
I am trying to use Vault as a OIDC Provider to fetch access_token.
My use case,
I have React App where user will be able to update their secrets (Ex. path “test-secret/Account.json”)
To fetch the access_token I am using Vault as a OIDC provider,
Steps:

1. React App Login page will redirect user to Vault
2. Using Vault userpass auth method, user will authenticate himself
3. Vault will redirect them to React App with code
4. React App will call OIDC Token API to fetch token
5. React App will update secret using Secret Engine API and access_token

I have followed OIDC Provider docs(Vault as an OIDC identity provider | Vault | HashiCorp Developer). Not Setup Boundary

Created a new Policy

path "test-jira-secrets/*" {
  capabilities = ["create", "update", "patch", "read", "delete", "list"]
}

path "sys/mounts" {
  capabilities = ["read", "list"]
}

# Mount the OIDC auth method
path "sys/auth/oidc" {
  capabilities = [ "create", "read", "update", "delete", "sudo" ]
}

# Configure the OIDC auth method
path "auth/oidc/*" {
  capabilities = [ "create", "read", "update", "delete", "list" ]
}

# Write ACL policies
path "sys/policies/acl/*" {
  capabilities = [ "create", "read", "update", "delete", "list" ]
}

# List available secrets engines to retrieve accessor ID
path "sys/mounts" {
  capabilities = [ "read" ]
}

Created a new user with above policy

Authentication working and I am getting access_token

{
    "access_token": "hvb.AAAAAQK8kNhe1ykh_h1aFAAZi5LRdOdndl5Zx5HzQH5RimUQLgrUuveIi1iSX9DDzS1rk5ZzvP05DJTfMFK_kA7AzN0igqiLIfBAYCJKsfaVmpvo3RMzieesW5VuAjHA12374JNUoOjRqMM3WE7P8NjAqb_AL5razIRFIidS2Jr3RaNYFZXuyJbFhomcecEgitFyNfcKIrk2l8ZFxgzzfrLrBrH6Z55rX2NUBuh6BZMEVTEro6Y3eU60oR2PMhJFsAjrfGsfNgmllmo5tTdjrz3IxtwJrDkb70atA2Wc8bmU4Vk-Hz-xsdwodNz7dIa6O7MNz85xSoAZ9lmB7E3ft7sS9izBkfdXinVBGSMRnwj6H43f_qWS4nxRShbXrqNu0vii1tMkSS0nEcfa6q8rRKdxBHArEVaeqSf9P0_TV9YnmdfYdteDhCzlmdeunNqOupg0C4erX-c",
    "expires_in": 86400,
    "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjlmOGRiZDFiLTkyZWUtN2ZlNS04ZjEzLTRmNTdjNjU2ZWI0MSJ9.eyJhdF9oYXNoIjoielhCb0U5NTZBWS1QYUo3WU5CbkU2dyIsImF1ZCI6Im9wQ3Jjb0ozUkxPeGFQallNUlVGU0hWVU9hejJJQWV2IiwiY19oYXNoIjoiOC1nM1FkRk9TOWRubHJMRFV1TXdDUSIsImNvbnRhY3QiOnsiZW1haWwiOiIiLCJwaG9uZV9udW1iZXIiOiIifSwiZXhwIjoxNjkyODcwNzkyLCJncm91cHMiOm51bGwsImlhdCI6MTY5Mjc4NDM5MiwiaXNzIjoiaHR0cDovLzAuMC4wLjA6ODIwMC92MS9pZGVudGl0eS9vaWRjL3Byb3ZpZGVyL2RlZmF1bHQiLCJuYW1lc3BhY2UiOiJyb290Iiwibm9uY2UiOiJhYmNkZWZnaGlqayIsInN1YiI6ImMzOTRhNDUxLWRiZWMtZTk3Yi1kMTQzLTM5MWQwYjZmMzk1NSIsInVzZXJuYW1lIjoiVGVzdCBVc2VyIn0.tdWrMN8fjPJA0NNfU5_dUo-xs6tOWWJG6_i5zM1eJjM1BLSDwyB9c1kfP93ETcDPYcI1EAAq7HDDz-O_k3msiTxXirzK9A4QW-tj9wWJduuKaPdZvTuKUoOAwz-7lcv-2-KqGATKWhodJhlpsMKhB3aIP1DXLTaScP5s2jAnPssvm6DKaSEinhuqR7FNzUdSmxbh4R6p021bezvqIvyPXMta0xSLSHW3nEziSiXt0nxHNKQL5NMWEgd7TsZCwaXItZqVjUrLilCjmbSeFy2V-mu7HRguyOR0B3Hj17IIzkJ3vK8_IY1F_1ju3Fpwr7PPzceOC6GUCgiraEJm0o2Uzg",
    "token_type": "Bearer"
}

Now, The issue I am facing is that,
Using this access_token, I am not able to fetch KV Secret Engine secrets

API:

curl --request GET \
  --url 'http://localhost:8200/v1/test-jira-secrets/data/Account.json?version=1' \
  --header 'Authorization: Bearer hvb.AAAAAQK8kNhe1ykh_h1aFAAZi5LRdOdndl5Zx5HzQH5RimUQLgrUuveIi1iSX9DDzS1rk5ZzvP05DJTfMFK_kA7AzN0igqiLIfBAYCJKsfaVmpvo3RMzieesW5VuAjHA12374JNUoOjRqMM3WE7P8NjAqb_AL5razIRFIidS2Jr3RaNYFZXuyJbFhomcecEgitFyNfcKIrk2l8ZFxgzzfrLrBrH6Z55rX2NUBuh6BZMEVTEro6Y3eU60oR2PMhJFsAjrfGsfNgmllmo5tTdjrz3IxtwJrDkb70atA2Wc8bmU4Vk-Hz-xsdwodNz7dIa6O7MNz85xSoAZ9lmB7E3ft7sS9izBkfdXinVBGSMRnwj6H43f_qWS4nxRShbXrqNu0vii1tMkSS0nEcfa6q8rRKdxBHArEVaeqSf9P0_TV9YnmdfYdteDhCzlmdeunNqOupg0C4erX-c'

Response:

{
	"errors": [
		"1 error occurred:\n\t* permission denied\n\n"
	]
}

I think my config is wrong somewhere as
I have tried token_lookup API:
API:

curl --request POST \
  --url http://127.0.0.1:8200/v1/auth/token/lookup \
  --header 'Content-Type: application/json' \
  --header 'X-Vault-Token: hvs.U67nCqYxyehzoe8MtnkPigWO' \
  --data '{
	"token": "hvb.AAAAAQK8kNhe1ykh_h1aFAAZi5LRdOdndl5Zx5HzQH5RimUQLgrUuveIi1iSX9DDzS1rk5ZzvP05DJTfMFK_kA7AzN0igqiLIfBAYCJKsfaVmpvo3RMzieesW5VuAjHA12374JNUoOjRqMM3WE7P8NjAqb_AL5razIRFIidS2Jr3RaNYFZXuyJbFhomcecEgitFyNfcKIrk2l8ZFxgzzfrLrBrH6Z55rX2NUBuh6BZMEVTEro6Y3eU60oR2PMhJFsAjrfGsfNgmllmo5tTdjrz3IxtwJrDkb70atA2Wc8bmU4Vk-Hz-xsdwodNz7dIa6O7MNz85xSoAZ9lmB7E3ft7sS9izBkfdXinVBGSMRnwj6H43f_qWS4nxRShbXrqNu0vii1tMkSS0nEcfa6q8rRKdxBHArEVaeqSf9P0_TV9YnmdfYdteDhCzlmdeunNqOupg0C4erX-c"
}'

Response:

{
	"request_id": "4f04d07e-3763-8bfa-1edf-d8dd72240453",
	"lease_id": "",
	"renewable": false,
	"lease_duration": 0,
	"data": {
		"accessor": "",
		"creation_time": 1692784392,
		"creation_ttl": 86400,
		"display_name": "",
		"entity_id": "c394a451-dbec-e97b-d143-391d0b6f3955",
		"expire_time": "2023-08-24T09:53:12Z",
		"explicit_max_ttl": 0,
		"id": "hvb.AAAAAQK8kNhe1ykh_h1aFAAZi5LRdOdndl5Zx5HzQH5RimUQLgrUuveIi1iSX9DDzS1rk5ZzvP05DJTfMFK_kA7AzN0igqiLIfBAYCJKsfaVmpvo3RMzieesW5VuAjHA12374JNUoOjRqMM3WE7P8NjAqb_AL5razIRFIidS2Jr3RaNYFZXuyJbFhomcecEgitFyNfcKIrk2l8ZFxgzzfrLrBrH6Z55rX2NUBuh6BZMEVTEro6Y3eU60oR2PMhJFsAjrfGsfNgmllmo5tTdjrz3IxtwJrDkb70atA2Wc8bmU4Vk-Hz-xsdwodNz7dIa6O7MNz85xSoAZ9lmB7E3ft7sS9izBkfdXinVBGSMRnwj6H43f_qWS4nxRShbXrqNu0vii1tMkSS0nEcfa6q8rRKdxBHArEVaeqSf9P0_TV9YnmdfYdteDhCzlmdeunNqOupg0C4erX-c",
		"issue_time": "2023-08-23T09:53:12Z",
		"meta": {
			"oidc_token_type": "access token"
		},
		"num_uses": 0,
		"orphan": true,
		"path": "oidc/provider/default/token",
		"policies": null,
		"renewable": false,
		"ttl": 82238,
		"type": "batch"
	},
	"wrap_info": null,
	"warnings": null,
	"auth": null
}

As you see the access_token does not have any policy, but User and Entity both has default and test-jira-secrets policy attached to it.

So, If anyone has idea about it then please help.

[maxb]

OIDC is like a selection of parts you can assemble in various ways to do different kinds of access management.

You’ve assumed that Vault implements the bits of OIDC needed for delegated access to the Vault API, by an application, on behalf of another user.

I don’t think that’s actually true.

I’m pretty sure Vault implements only the bits of OIDC needed for another application to get a proof of which user is logged in - using Vault as a single sign on system for other applications. You cannot use the resulting access token to access the Vault API. The only thing you can do with it is invoke https://developer.hashicorp.com/vault/api-docs/secret/identity/oidc-provider#userinfo-endpoint to find out which user the access token is for.

[nisarg.bhatt]

So, To change the secret apart from Vault UI, I have to use auth method mounted on vault.
Got it. Thanks for the help @maxb .

[matifali]

I am facing a similar issue where the token received by OIDC flow does not have the required policies to fetch vault tokens. I am just wondering if it is even possible to get a vault token using OIDC flow that can have the correct policies.

[nisarg.bhatt]

Using Vault as OIDC Provider you can not get vault_access_token with vault policy.
If you want to use OIDC flow then use Vault Auth method oidc and use Auth0, Okta or Keycloak as OIDC provider.

Also Vault OIDC Provider is also not fully OpenID Compliant so you can not even use Vault Auth Method oidc in Vault’s OIDC Provider (like daisy chaining).

[matifali]

Thank you. What would be a suitable flow for setting it up while I want my users to auth to vault using Google auth. I have already set up google oidc with Vault.
Now I want my other app specifically Coder to access secrets in vault by using an OIDC flow.