Equinox OAuth 2.0 Federated Authorization

Project Overview

• Name: Equinox OAuth 2.0 / OIDC Federated Authorization
• Type: Cross-service authorization layer for the Infosys Equinox commerce platform
• Context: Enterprise, closed-source (Infosys proprietary, IP-protected)
• Purpose: Design and roll out a standards-based OAuth 2.0 / OpenID Connect authorization layer, then integrate it across a set of existing backend microservices so they share one consistent, federated authorization model.

This work added a modern, RFC-aligned authorization surface (authorization code flow with PKCE, token issuance, introspection, revocation, and discovery) on top of services that previously relied on a bespoke session and token scheme, and wired it together across service boundaries.

My Role and Scope

I designed and implemented the OAuth 2.0 / OIDC authorization layer and integrated it across four existing services. The important distinction:

• What I built: the OAuth / OIDC authorization layer itself - the authorization server behavior (authorize, token, introspection, revocation, discovery), PKCE enforcement (both the server-side verification and the public-client browser-side challenge generation), client and key management for OAuth clients, and the cross-service integration that lets the platform present a single federated authorization model.
• What I did NOT build: the underlying microservices themselves. Those services already existed and were owned by their respective teams. My contribution was the authorization layer and its federated rollout across them, not the base service functionality.

The four services involved in the integration:

• Authentication / authorization service - host of the authorization server endpoints, token lifecycle, OAuth client registration, and key material.
• User identity service - the user and identity records that back the subject of issued tokens.
• Admin orchestration service - the orchestration tier that routes admin-facing auth and session calls through to the authorization layer.
• Common admin / login experience - the login and consent front end, including the public-client (browser) side of the PKCE flow.

Key Capabilities

OAuth 2.0 / OIDC Flows

• Authorization Code flow with PKCE as the primary, recommended path, available over both a browser redirect entry point and an API-style entry point for first-party integrations.
• OIDC support - ID token issuance, nonce handling for replay mitigation, and scope-based access (for example openid, profile, email).
• Refresh token support, including a refresh path for public (PKCE) clients that hold no client secret.
• Client credentials support for service-to-service callers.
• Standards-compliant redirect handling - authorization code returned via query, token and ID token returned via fragment, with state echoed back and RFC-style error redirects on failure.

PKCE (Internal and External)

• External / public clients (browser-based storefront and admin login experiences) generate the code challenge client side and complete the exchange with a code verifier.
• Internal verification - the authorization layer validates the verifier against the stored challenge on token exchange, supporting both S256 (SHA-256) and plain challenge methods, and rejects mismatches.
• The login experience is origin-aware, so storefront-origin and admin-origin clients are routed to the appropriate login surface while preserving the original authorization parameters across the login redirect.

Token Introspection and Revocation

• Introspection - a dedicated endpoint that returns the active or inactive state and associated metadata of a token, so resource services can validate tokens without owning the signing keys.
• Revocation - a dedicated endpoint to invalidate issued tokens and end the associated client session.

Discovery and Key Distribution

• Authorization server metadata published at the standard well-known discovery document, advertising the issuer, the authorization and token endpoints, the JWKS location, supported scopes, response types, grant types, and supported PKCE challenge methods.
• Protected resource metadata published at the standard well-known location so resource servers can advertise their authorization servers and scopes.
• JWKS publication so clients and resource servers can fetch the public keys needed to verify token signatures.
• Dynamic OAuth client registration with managed client identifiers, secrets for confidential clients, and redirect URI registration.

Architecture (High Level)

• A single authorization layer acts as the issuer and authority for the platform. The other services either delegate their login and consent experience to it, route their admin auth and session traffic through it, or rely on it as the source of identity for issued tokens.
• This is a federated, cross-service rollout: rather than each service implementing its own token scheme, the authorization model is centralized and the integration threads it through service boundaries. The hard part was less the standalone server and more making four independently owned services agree on one consistent authorization contract without breaking their existing consumers.
• Backward compatibility was a first-class constraint. The new standards-based endpoints coexist with the platform's pre-existing session and token mechanisms, and legacy request shapes continue to resolve, so the migration could be incremental rather than a hard cutover.

Standards and Security

• RFC 6749 - OAuth 2.0 core, authorization code flow and error redirect semantics.
• RFC 7636 - PKCE, with S256 and plain challenge methods.
• RFC 8414 / OIDC Discovery - authorization server metadata document.
• RFC 9728 - OAuth protected resource metadata.
• RFC 7662 - token introspection.
• RFC 7009 - token revocation.
• RFC 7519 - JWT, for the structure of issued tokens.

Security posture follows OAuth 2.1 hardening guidance applied to an OAuth 2.0 / OIDC base: PKCE is enforced on the authorization code flow, authorization codes are single-use and time-bound, state and nonce are used to mitigate CSRF and replay, and introspection lets resource services validate tokens centrally. (The server retains an implicit response path for backward compatibility with existing consumers, so the model is best described as OAuth 2.0 / OIDC with OAuth 2.1 security hardening rather than a strict OAuth 2.1 profile.) Authorization actions are audited for traceability.

Technical Stack

• Language and Framework: Java with Spring Boot and Spring Security
• Protocols and Standards: OAuth 2.0, OpenID Connect, PKCE, JWT, OAuth 2.1 security hardening
• Persistence: relational store for OAuth clients, authorization codes, and client sessions
• Integration: cross-service orchestration routing and a browser-based login and consent experience
• Cryptography: SHA-256 for PKCE verification; asymmetric keys published via JWKS for token signature verification

This authorization layer gives Infosys Equinox a single, standards-aligned, federated OAuth 2.0 / OIDC model shared across multiple existing backend services, replacing per-service token handling with consistent, RFC-compliant authorization.