Vault OIDC Auth: SSO Integration for Developer Access (2026)

Vault’s OIDC auth method, when integrated with your SSO provider, doesn’t just offer a convenient way for developers to log in; it fundamentally shifts how you manage access to secrets by treating identity as the primary credential, not just a gatekeeper.

Let’s see it in action. Imagine a developer, Alice, needs to access a database secret stored in Vault. Instead of a static Vault token or a separate user account in Vault, Alice uses her company SSO (like Okta, Azure AD, or Google Workspace).

Here’s a simplified flow:

1. Alice initiates access: Alice navigates to a protected resource or tries to authenticate with Vault using her SSO credentials.
2. Vault redirects to SSO: Vault, configured with the OIDC auth method, redirects Alice’s browser to her SSO provider.
3. Alice authenticates with SSO: Alice logs in to her SSO provider using her standard company username and password (or any other MFA method configured).
4. SSO issues an ID Token: Upon successful authentication, the SSO provider issues an OpenID Connect ID Token (a JWT) back to Vault. This token contains claims about Alice’s identity (e.g., her email, groups she belongs to, employee ID).
5. Vault validates the ID Token: Vault verifies the signature of the ID Token using the SSO provider’s public keys and checks its validity (expiration, issuer, audience).
6. Vault generates a Vault Token: If the ID Token is valid and contains expected claims, Vault uses the information within the token to generate a Vault token for Alice. This Vault token is then returned to Alice’s client.
7. Alice uses the Vault Token: Alice can now use this Vault token to interact with Vault and access the database secret, subject to policies defined in Vault based on the claims from her ID Token.

The core problem this solves is the brittle nature of traditional access management where credentials (like static tokens or user accounts) are often long-lived, difficult to rotate, and don’t inherently tie access to an individual’s real-time identity status. OIDC auth leverages your existing, robust identity provider to grant temporary, context-aware access to Vault.

Internally, Vault’s OIDC auth method acts as a client to your SSO provider. When you enable the oidc auth method, you provide Vault with the SSO provider’s:

• Issuer URL: The base URL of your SSO provider’s OIDC endpoint (e.g., https://dev-12345.okta.com/oauth2/default).
• Client ID: A unique identifier for Vault within your SSO provider.
• Client Secret: A secret key Vault uses to authenticate itself to the SSO provider.
• JWKS URL: The URL where Vault can fetch the JSON Web Key Set (JWKS) used to verify the signature of the ID Tokens issued by the SSO provider.

Vault’s role is to:

1. Discover Endpoints: Fetch the OIDC discovery document from the issuer URL to find all necessary endpoints (authorization, token, JWKS).
2. Issue Authentication Requests: Redirect users to the SSO provider’s authorization endpoint.
3. Validate ID Tokens: Crucially, this involves verifying the JWT signature using keys from the JWKS URL and checking standard claims like iss (issuer), aud (audience), and exp (expiration).
4. Map Claims to Vault Policies: This is where the magic happens. You configure Vault to map specific claims from the validated ID Token (e.g., a user’s email or membership in a groups claim) to Vault policies. This means Alice’s access is dynamically determined by her group memberships or attributes in her SSO, not by a static Vault user entry.

The exact levers you control are:

• oidc_discovery_url: The base URL of your identity provider’s OIDC endpoint.
• client_id: Vault’s identifier for your identity provider.
• client_secret: Vault’s secret for authenticating to your identity provider.
• oidc_scopes: The scopes Vault requests from the identity provider (e.g., openid, email, profile, groups). The groups scope is essential for policy-based access.
• token_policies: A list of Vault policies that will be attached to any token generated by this auth method, before any user-specific policies are applied.
• token_ttl: The default Time-To-Live for generated Vault tokens.
• user_claim: The claim in the ID token that Vault will use as the unique identifier for the user (often email or sub).
• groups_claim: The claim in the ID token that contains the user’s group memberships (often groups or roles).

One thing most people don’t realize is that the oidc_scopes you define in Vault’s OIDC auth method configuration must also be requested by Vault from your SSO provider during the authentication flow. If you configure oidc_scopes = ["openid", "email", "profile", "groups"] in Vault, but your SSO application configuration only allows openid and email, the groups claim won’t be present in the ID token, and Vault won’t be able to use it for policy mapping, leading to unexpected access restrictions. This requires a two-way configuration: Vault must ask for the scopes, and the SSO provider must grant them to the Vault application.

Once you have OIDC auth configured and working, the next logical step is to explore how to automate the rotation of the client_secret used by Vault to authenticate with your SSO provider.