A comprehensive guide to OIDC authentication, implementation patterns, and integration with Delinea Secret Server.
OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0 that enables secure, standardized user authentication across applications.
OIDC is an open authentication protocol that sits on top of OAuth 2.0. It standardizes how applications verify the identity of end-users based on authentication performed by an Authorization Server, and obtain basic profile information via REST-like APIs.
OAuth 2.0 handles authorization — granting access to resources. OIDC adds authentication — confirming who the user is. Together they provide a complete identity and access management framework.
OIDC introduces the ID Token — a JWT (JSON Web Token) containing claims about the authenticated user: their identity, when they authenticated, and by which provider. This token can be cryptographically verified.
Delinea Secret Server supports OIDC as both an Identity Provider (IdP) and a Relying Party (RP), enabling it to issue tokens for service accounts and accept tokens from external providers like Azure AD, Okta, or Ping Identity for SSO authentication.
The server that authenticates the user and issues tokens. In OIDC, the IdP exposes a /.well-known/openid-configuration discovery endpoint listing all its capabilities.
The application that delegates authentication to the IdP. After receiving an ID Token, the RP validates it cryptographically before granting access — it "relies" on the IdP's identity assertion.
A protected REST endpoint on the IdP that returns additional claims about the authenticated user. The RP presents an Access Token to retrieve attributes like email, groups, and department beyond what's in the ID Token.
OIDC defines several grant types for different application scenarios. Choose the correct flow based on your application's architecture and trust level.
state value.code token or code id_token to receive both a code and tokens in the front channel simultaneously.c_hash or at_hash claim in the ID Token to bind it to the auth code/access token received.groups) to Secret Server roles. Group membership from IdP can automatically grant vault folder access.Click any use case to explore Delinea-specific scenarios, implementation notes, and benefits.
Centralise login through an enterprise IdP — Azure AD, Okta, Ping Identity.
Pipelines retrieve secrets at runtime using client credentials — no hardcoded passwords.
Use OIDC tokens to launch privileged sessions without re-authenticating.
Native/mobile apps use PKCE flow for secure, passwordless vault access.
Serve different business units with isolated OIDC tenants from one Secret Server.
Every secret access request validated against fresh OIDC claims — no implicit trust.
Follow these steps to configure OIDC authentication with Delinea Secret Server. Track your progress as you go.
Before configuring Secret Server, you must register it as an OIDC client application in your Identity Provider (Azure AD, Okta, Ping Identity, etc.).
The Redirect URI must exactly match what you configure in Secret Server. A mismatch will cause authentication failures — even a trailing slash difference matters.
https://your-secretserver/signin-oidcopenid profile email groups# Register Secret Server as OIDC app in Azure AD $app = New-AzADApplication ` -DisplayName "Delinea Secret Server" ` -ReplyUrls "https://secretserver.corp.com/signin-oidc" ` -AvailableToOtherTenants $false # Create client secret (note: rotate every 90 days) $cred = New-AzADAppCredential ` -ApplicationId $app.AppId ` -EndDate (Get-Date).AddDays(90) # Output discovery URL $tenantId = (Get-AzContext).Tenant.Id Write-Output "Discovery URL: https://login.microsoftonline.com/$tenantId/v2.0/.well-known/openid-configuration" Write-Output "Client ID: $($app.AppId)"
Navigate to Admin → Configuration → Login → OpenID Connect in Secret Server to enter the IdP details.
# POST to Secret Server API to configure OIDC provider POST /api/v1/configuration/oidc/providers Authorization: Bearer {admin_token} Content-Type: application/json { "name": "Corporate Azure AD", "clientId": "a1b2c3d4-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "clientSecret": "~YourClientSecretHere~", "discoveryUrl": "https://login.microsoftonline.com/{tenantId}/v2.0/.well-known/openid-configuration", "scopes": ["openid", "profile", "email", "groups"], "responseType": "code", "enablePkce": true, "autoProvisionUsers": true, "active": true }
code_challenge_method=S256) even for confidential clientsSecret Server automatically fetches the IdP's .well-known/openid-configuration document to populate all required endpoint URLs, supported algorithms, and JWKS URI. Always prefer this over manual endpoint entry.
Claims mapping connects OIDC token claims to Secret Server user attributes and roles. Group claims drive automatic role assignment.
{
"sub": "1234567890-abcdef", // Unique user ID
"name": "Jane Smith",
"email": "jsmith@corp.com",
"email_verified": true,
"groups": [
"SS-VaultAdmins",
"SS-UnixOperators"
],
"iss": "https://login.microsoftonline.com/{tenant}/v2.0",
"aud": "a1b2c3d4-xxxx-xxxx-xxxx-xxxxxxxxxxxx", // Must match client_id
"iat": 1700000000,
"exp": 1700003600,
"nonce": "abc123xyz" // Replay protection
}
Use AD security groups that mirror Secret Server roles (e.g., SS-Admins, SS-Operators). When a user is added to the AD group, they automatically get the corresponding SS role on next login — no manual SS admin action needed.
Secret Server validates every ID Token before granting access. Understanding this validation chain helps troubleshoot issues and ensures proper security posture.
// Secret Server performs these checks on every ID Token validateToken(idToken) { // 1. Signature — fetch public key from JWKS URI verifySignature(idToken, jwksUri); // 2. Issuer (iss) must match configured IdP assert(idToken.iss === configuredIssuer); // 3. Audience (aud) must include our client_id assert(idToken.aud.includes(clientId)); // 4. Expiry (exp) must be in the future assert(idToken.exp > Date.now() / 1000); // 5. Issued-at (iat) not too far in the past assert(Date.now() / 1000 - idToken.iat < 300); // 6. Nonce matches what was sent in auth request assert(idToken.nonce === sessionNonce); // 7. Algorithm (alg) must be RS256 or ES256 assert(['RS256', 'ES256'].includes(idToken.header.alg)); }
Always explicitly whitelist permitted signing algorithms. Accepting none or HS256 with a shared secret from an untrusted source allows token forgery attacks. Secret Server enforces RS256/ES256 by default — do not override this.
Before enabling OIDC for all users, validate the configuration with a test user and confirm all expected behaviours.
# Fetch and inspect IdP discovery document curl -s "https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration" \ | python3 -m json.tool # Verify JWKS endpoint is accessible from Secret Server host curl -s "https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys" \ | python3 -c "import sys,json; keys=json.load(sys.stdin)['keys']; print(f'{len(keys)} signing keys found')" # Test token decode (replace TOKEN with actual JWT) TOKEN="eyJhbGc..." echo $TOKEN | cut -d. -f2 | base64 -d 2>/dev/null | python3 -m json.tool
Once all checklist items are confirmed, navigate to Admin → Configuration → Login and set the OIDC provider as the default login method. Consider a phased rollout — enable for a pilot group first before enforcing org-wide.
Why invest in OIDC integration? Here are the operational, security, and compliance benefits organisations realise.
Users authenticate once via their corporate IdP and gain vault access without a separate Secret Server password. Reduces the credential attack surface and eliminates password fatigue across multiple systems.
OIDC delegates authentication to the enterprise IdP, which can enforce phishing-resistant MFA (FIDO2, hardware tokens) before issuing tokens. Secret Server inherits this security without managing MFA itself.
User onboarding/offboarding propagates automatically. When IT disables a user in Azure AD or Okta, their OIDC tokens stop being issued — access to Secret Server terminates without any vault admin action.
Authentication events are recorded at both the IdP and Secret Server. Security teams get a unified view of who accessed the vault, from which device, with what authentication method — critical for compliance reporting.
Group membership in AD/IdP directly drives vault permissions. Add a user to the "SS-DBAdmins" group and they immediately gain access to database credential folders — consistent RBAC without manual vault configuration.
CI/CD pipelines use Client Credentials flow to retrieve secrets at build/deploy time via short-lived tokens. No static service account passwords in config files, environment variables, or source code.
Test your understanding of OIDC and its application within Delinea Secret Server.
Key OIDC and PAM terms for quick reference.
/.well-known/openid-configuration advertising all IdP endpoints, supported scopes, and algorithms.