Hey there! Let's dive into your problem and your proposed solution—this is a super common scenario when dealing with legacy or third-party identity systems that don't speak the same protocol.

Is Your Proposed Custom Middleware Solution Feasible? #

Short answer: Absolutely. What you're describing is exactly an identity protocol bridge (or "protocol translation gateway"), a well-established pattern for connecting IdPs and SPs that use incompatible protocols. Many organizations rely on this approach when they can't modify the underlying services, so your plan is totally valid.

Pros of the Custom Middleware Approach #

• No changes to existing services: This is the biggest win—since you can't modify either the OIDC IdP or SAML SP, the bridge acts as a seamless translator between them, keeping your existing systems untouched.
• User experience transparency: From the end user's perspective, the flow feels like a normal single sign-on (SSO) process: they get redirected to the familiar IdP login page, log in, and land directly on the SP. No extra steps or confusing interfaces.
• Full control over logic: A custom bridge lets you tweak the flow to fit your specific needs—like mapping OIDC user claims to SAML attributes the SP expects, adding extra authorization checks, or custom error handling for edge cases.
• Mature tooling support: You don't have to build everything from scratch. Most languages have robust libraries for handling OIDC (e.g., oidc-client for JavaScript, Spring Security OAuth2 for Java) and SAML (e.g., saml2-js for Node.js, OpenSAML for Java) to simplify the heavy lifting of token validation, assertion signing, etc.

Cons of the Custom Middleware Approach #

• Added operational overhead: You'll have to maintain this new service: deploy it, monitor uptime, apply security patches, manage logs, and scale it if needed. It's an extra failure point in your SSO flow, so you'll need to plan for redundancy.
• Security responsibility: The bridge becomes a critical security node. You'll need to securely store sensitive data like OIDC client secrets, SAML signing private keys, and ensure all communications are encrypted (HTTPS only). You also have to implement proper validation for OIDC tokens (checking signatures, issuer, expiration) and SAML assertions to prevent spoofing or tampering.
• Protocol complexity: While the high-level flow is straightforward, the details can get messy. You'll need to align with the SP's SAML metadata (like required attributes, signature algorithms, assertion consumer service URLs) and the IdP's OIDC configuration (scopes, token endpoints). Debugging protocol errors can be time-consuming, especially if either service has strict or non-standard requirements.
• Performance overhead: Each SSO request adds an extra hop through the bridge, which can introduce minor latency. For most use cases this is negligible, but it's worth considering if you have high-traffic or latency-sensitive applications.

Better Alternatives (If Custom Development Isn't Ideal) #

If building and maintaining a custom bridge feels like too much work, there are off-the-shelf options that solve this problem out of the box:

• Commercial identity bridge services: Tools like Ping Identity, OneLogin, Okta, or Azure AD all support OIDC-to-SAML protocol conversion as part of their SSO offerings. These are managed services, so you don't have to worry about hosting, security, or maintenance—you just configure the connections between your IdP and SP. They also come with support teams to help troubleshoot any issues.
• Open-source identity gateways: Keycloak is a popular open-source identity and access management tool that works great as a protocol bridge. You can configure it to act as an SP for your OIDC IdP, then as an IdP for your SAML SP—all through a web UI, no custom code needed. It's free, highly customizable, and has a large community for support.
• Reverse proxy extensions: Some enterprise reverse proxies (like NGINX Plus) have modules that can handle OIDC authentication and translate it to SAML for backend services. This is a good option if you already use a reverse proxy in your infrastructure, though it's less flexible than dedicated identity tools.

Final Takeaway #

Your custom middleware plan is solid and absolutely worth considering if you need full control over the SSO flow and have the resources to build and maintain it. That said, if you want to reduce operational burden and risk, going with a commercial service or open-source gateway like Keycloak is often a more efficient choice—they've already solved all the edge cases and security problems you might run into.

内容的提问来源于stack exchange，提问作者Curious Blueprints