13 Deepening security with OpenID Connect

As organizations expand and introduce Single Sign-On, they benefit from separating authentication from application backends and adopting standards that balance security and usability. OAuth 2.0 provides delegated authorization, while OpenID Connect (OIDC) layers identity on top, enabling apps to confirm who a user is in a consistent, interoperable way. This chapter deepens those foundations by showing how to harden the Authorization Code flow, keep sessions smooth without sacrificing safety, leverage OIDC’s identity features, and scale securely across multiple tenants.

To defend the Authorization Code flow—especially for public clients like mobile and SPA—PKCE pairs a one-time code verifier with a hashed code challenge so only the original client can redeem an intercepted code; use the S256 method and treat PKCE as mandatory per OAuth 2.1, while noting it’s unnecessary for machine-to-machine flows. Since short-lived access tokens reduce risk but can annoy users, refresh tokens allow seamless renewal; secure them with TLS, appropriate storage, limited scopes, rotation on use, expiration, and rapid revocation, and pair them with PKCE for public clients to curb abuse.

OIDC enriches identity with an ID token (always a JWT) that conveys verified user claims, a UserInfo endpoint for additional profile data, and built-in defenses like nonce and state to thwart replay and CSRF. It standardizes session management and logout—supporting silent checks, RP-initiated logout, and single logout—for consistent cross-application behavior. For multitenancy, a single IdP can serve many isolated tenants through tenant-specific endpoints, branding, and configuration, embedding tenant-aware claims (such as tenant identifiers, roles, and permissions), enabling per-tenant RBAC, dynamic client registration, and strictly isolated sessions to prevent cross-tenant leakage.

The Authorization Code Grant Flow. The client application requests access to resources protected by a backend application (resource server) on behalf of a user. To initiate this process, the client redirects the user to authenticate with a trusted authorization server. Upon successful authentication, the client receives an authorization code, which it then exchanges for an access token. With a valid access token, the client can securely access the protected resources hosted by the backend application.

Proof Key for Code Exchange (PKCE) Flow. Before initiating the authentication process, the client generates a unique and random pair of values: a code challenge and a code verifier. The client uses this pair throughout the authorization flow to enhance security, ensuring no unauthorized party can intercept or misuse the authentication process to impersonate the user.

Relationship Between Code Verifier and Code Challenge. The code verifier is a securely generated random value. The code challenge is derived by applying a cryptographic hash function (commonly SHA-256) to the code verifier. This one-way transformation strengthens the security of the authorization process by ensuring the verifier cannot be reverse-engineered from the challenge.

The Refresh Token flow. When a client is registered to use refresh tokens, it receives both an access token and a refresh token from the authorization server. The client can later use the refresh token to seamlessly request a new access token without requiring any additional user interaction. This approach maintains security while providing a smoother, uninterrupted user experience.

OAuth 2.0 is like a bouncer at a club—it checks if you're allowed to enter but has no idea you're a VIP member.

Illustration of a Replay Attack—An attacker intercepts and maliciously resends a previously valid request to trigger unauthorized actions or changes within the system.

Example of a Replay Attack with Data Tampering—If cryptographic signing is not used, a hacker can intercept and modify a transaction. In this case, the attacker increases the transaction amount and redirects the payment to their own account instead of the legitimate shop's account.

Using a nonce with a properly signed transaction prevents hackers from replaying or modifying the request, ensuring the transaction is secure and unique.

Cross-Site Request Forgery (CSRF)—An attacker tricks a logged-in user into unknowingly sending a malicious request to a trusted website. Because the user is already authenticated, the server treats the request as legitimate and executes unauthorized actions, potentially leading to unintended changes or data exposure.

Cross-Site Request Forgery (CSRF) Tokens—The server issues a unique, secret token to the client, which must be included in all subsequent requests. If the token is missing, invalid, or incorrect, the server rejects the request. Since the attacker does not know this token, they cannot craft a valid request, preventing them from tricking the user into executing unauthorized actions.

Without centralized session management, users may unintentionally leave multiple sessions open across different devices or applications, increasing the risk of unauthorized access and potential security breaches.

• Proof Key for Code Exchange (PKCE) strengthens the Authorization Code Flow by preventing authorization code interception, especially for public clients like mobile and web apps.
• Refresh Tokens allow applications to maintain user sessions without repeatedly prompting for login, banacing security (by limiting access token lifespan) and user experience (by reducing interruptions).
• OpenID Connect’s Identity Layer introduces the ID Token, securely providing user identity information alongside the access token, enabling applications to authenticate users safely and reliably.
• The UserInfo Endpoint allows applications to retrieve additional user profile information in a standardized and secure manner, complementing the ID Token.
• OIDC enhances security against Replay Attacks and Cross-Site Request Forgery (CSRF) by using security parameters like nonce and state, ensuring requests are legitimate and unique.
• Session Management and Logout are standardized in OIDC, allowing consistent user session handling and Single Logout (SLO) across multiple connected applications, improving both security and user experience.
• Multitenancy with OIDC enables Acme Commerce Cloud to securely serve multiple tenants with distinct authentication flows, custom branding, isolated sessions, and tenant-specific roles and permissions—all from a single identity provider.
• Best Practices include always using PKCE with public clients, securely storing refresh tokens, enabling refresh token rotation, and enforcing secure communication with TLS/SSL.

FAQ