OpenID Connect for Enterprise Authentication and SSO

Overview

OpenID Connect (OIDC) is an identity protocol built on OAuth 2.0 that lets applications verify a user's identity and obtain profile claims through signed tokens and standardized endpoints. Enterprises use OIDC to centralize authentication, enable single sign-on (SSO), reduce password sprawl, and integrate cloud, SaaS, and internal applications with a common trust model.

OIDC is especially useful when organizations need browser-based login, federation with external identity providers, conditional access, and API-aware authentication flows. In practice, OIDC is commonly delivered by platforms such as Keycloak, Microsoft Entra ID, Okta, and Auth0.

Architecture

Core components

• End User: the person authenticating.
• Client / Relying Party (RP): the application requesting authentication.
• OpenID Provider (OP): the identity provider that authenticates users and issues tokens.
• Authorization Endpoint: starts the login flow.
• Token Endpoint: exchanges the authorization code for tokens.
• UserInfo Endpoint: returns user claims when needed.
• JWKS Endpoint: publishes signing keys for token validation.

Deployment models

• Central enterprise IdP: one OP for internal and SaaS apps.
• Hybrid federation: enterprise OP trusts external partners or social IdPs.
• Cloud-native: apps use managed OIDC from Entra ID, Okta, or Auth0.
• Self-hosted: Keycloak or similar deployed in Kubernetes or VMs.

Data flow

1. User accesses the application.
2. Client redirects to the OP authorization endpoint.
3. User authenticates with MFA and policy checks.
4. OP returns an authorization code to the client redirect URI.
5. Client exchanges the code for id_token, access_token, and optionally refresh_token.
6. Client validates issuer, audience, signature, expiry, and nonce.
7. Application creates a local session and applies authorization based on claims or groups.

Implementation Guide

This example uses Keycloak as the OpenID Provider.

1. Start Keycloak locally for validation:

docker run --name keycloak -p 8080:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD='Str0ngAdmin!' quay.io/keycloak/keycloak:25.0.0 start-dev

1. Create a realm and confidential client:

export KC=http://localhost:8080
export TOKEN=$(curl -s -X POST "$KC/realms/master/protocol/openid-connect/token" -d 'username=admin' -d 'password=Str0ngAdmin!' -d 'grant_type=password' -d 'client_id=admin-cli' | jq -r .access_token)
curl -s -X POST "$KC/admin/realms" -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' -d '{"realm":"enterprise","enabled":true}'
curl -s -X POST "$KC/admin/realms/enterprise/clients" -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' -d '{"clientId":"portal-app","enabled":true,"publicClient":false,"redirectUris":["https://portal.example.com/callback"],"secret":"9b7f2d4c-7b3a-4d8a-a0a1-1b2c3d4e5f67","standardFlowEnabled":true,"directAccessGrantsEnabled":false}'

1. Configure the application to use discovery from https://id.example.com/realms/enterprise/.well-known/openid-configuration.
2. Enforce Authorization Code Flow with PKCE even for confidential web apps.
3. Validate JWTs using the OP JWKS endpoint and cache keys with rotation awareness.
4. Map enterprise groups such as finance-admin or hr-readonly into application roles.
5. Enable MFA, session timeout, refresh token rotation, and audit logging before production go-live.

Code Examples

spring:
  security:
    oauth2:
      client:
        registration:
          keycloak:
            client-id: portal-app
            client-secret: 9b7f2d4c-7b3a-4d8a-a0a1-1b2c3d4e5f67
            scope: openid,profile,email
            authorization-grant-type: authorization_code
            redirect-uri: "{baseUrl}/login/oauth2/code/{registrationId}"
        provider:
          keycloak:
            issuer-uri: https://id.example.com/realms/enterprise

curl -s -X POST "https://id.example.com/realms/enterprise/protocol/openid-connect/token" -H 'Content-Type: application/x-www-form-urlencoded' -d 'grant_type=authorization_code' -d 'client_id=portal-app' -d 'client_secret=9b7f2d4c-7b3a-4d8a-a0a1-1b2c3d4e5f67' -d 'code=SplxlOBeZQQYbYS6WxSbIA' -d 'redirect_uri=https://portal.example.com/callback'

import jwt, requests
issuer = "https://id.example.com/realms/enterprise"
config = requests.get(f"{issuer}/.well-known/openid-configuration", timeout=5).json()
jwks = requests.get(config["jwks_uri"], timeout=5).json()
key = jwt.PyJWKClient(config["jwks_uri"]).get_signing_key_from_jwt(id_token).key
claims = jwt.decode(id_token, key=key, algorithms=["RS256"], audience="portal-app", issuer=issuer)
assert claims["email_verified"] is True

Security Hardening

• Use Authorization Code Flow with PKCE; avoid implicit flow.
• Require TLS 1.2+ and HSTS on all redirect and token endpoints.
• Sign tokens with RS256 or ES256 and rotate keys on a defined schedule.
• Prefer short-lived access tokens and refresh token rotation.
• Validate iss, aud, exp, iat, nonce, and azp where applicable.
• Restrict redirect URIs to exact matches; never allow wildcards in production.
• Use group-to-role mapping with least privilege, for example finance-read instead of broad admin.
• Store client secrets in a vault such as HashiCorp Vault or cloud secret managers.

Comparison

Troubleshooting

1. Invalid redirect URI

Log sample:

2026-04-18 09:14:22,771 WARN  [org.keycloak.events] type=LOGIN_ERROR, realmId=enterprise, clientId=portal-app, error=invalid_redirect_uri, redirect_uri=https://portal.example.com/cb

Fix: register the exact callback URI and ensure scheme, host, path, and trailing slash all match.

2. JWT audience validation failed

Log sample:

oauthlib.oauth2.rfc6749.errors.InvalidTokenError: Invalid audience in id_token: expected portal-app, got account

Fix: verify the client ID used in the request and confirm the application validates against the intended audience.

3. Signature key not found after rotation

Log sample:

java.security.SignatureException: Signed JWT rejected: Another algorithm expected, or no matching key(s) found

Fix: refresh the JWKS cache, confirm the kid exists in the current JWKS, and avoid hardcoding signing certificates.

Best Practices

Do

• Use discovery and JWKS endpoints instead of static metadata.
• Centralize MFA and conditional access at the OP.
• Normalize claims such as email, groups, and preferred_username across apps.
• Log authentication events with correlation IDs for SIEM ingestion.

Don't

• Do not authorize users only by email domain; use explicit groups or roles.
• Do not keep long-lived bearer tokens in browser storage.
• Do not disable signature or issuer validation in nonproduction code and forget to re-enable it.

A concrete enterprise pattern is to authenticate users with OIDC, issue short-lived tokens, map IdP groups to app roles, and enforce API authorization separately with policy engines or gateway controls.