OIDC client consistency across multiple Vault instances for failover

Vault
1

Hi all! \o/

I’m currently configuring AppRoles with Ansible, using specific role_id and custom secret_id values that follow the same UUID format Vault uses when generating them.

Is it possible to do something similar for OIDC clients?

Here’s the scenario:
We have two Vault instances and would like both to share the same OIDC client configuration — specifically the same client_id and client_secret. This would allow seamless failover if one Vault becomes unavailable: our DNS health check could switch traffic to the second Vault, and all clients could continue authenticating via OIDC without needing separate configurations.

If this setup isn’t directly supported, is there any API-based method (export/import) or another approach to replicate or synchronize OIDC clients between Vault instances to achieve the same effect?

Thanks in advance!

2

I’ve not tried this specific scenario, but in theory …yes? I have set up multiple Vault clusters with my Okta dev account using the same configuration, getting the client ID and client secret from Okta:

Stepping back, I suppose this would be the same thing as configuring a Vault performance replica - it replicates all the auth method config over to the secondary.

3

Hi @jonathanfrappier

thanks for quick answer but not as oidc authentication, I mean using vault as IdP

vault 1

vault read identity/oidc/client/site-example.com
Key Value

access_token_ttl 1h
assignments [assignment-test]
client_id EFgs4…
client_secret hvo_secret_9a8HCkV…
client_type confidential
id_token_ttl 30m
key oidc-key1
redirect_uris https://site-example.com/callback

how can I set into vaul2 the same client_id and secret_id from vault1 using a cli

vault write …… ???

In our setup, we have a replicated cluster consisting of Vault1 (3 nodes) and Vault2 (3 nodes) located in a different region. Because of high latency, replication between Vault1 and Vault2 is not feasible, so we need to configure them as independent Vault clusters that contain the same data.

4

My bad for the misunderstanding - Vault auto generates those values (as I think most IdP’s do?). Have you tried taking a snapshot and restoring it to the remote/second cluster?

5

That could be a solution if we’re not planning to keep adding more OIDC clients.
We can’t perform a backup and restore every time we add new secrets just to simulate the replica.

if vault can extend a feature for OIDC to custom_client_id and custom_secret_id in the same keeping format as generated now we can add it like approles do and explained in the documentation.

same like transit secret engine, is possible to restore because have an export option.