An application and its identity provider do not have to support the same federation protocol. A modern application may use OpenID Connect while an established enterprise or partner identity provider still uses SAML 2.0. Rewriting either side solely to make the protocols match can add cost, migration risk and unnecessary dependencies.
A SAML to OpenID Connect bridge lets each side keep the protocol it already supports. FoxIDs validates the SAML 2.0 response from the external identity provider, applies the required claims and security rules, and issues the OpenID Connect response expected by the application.
Searches for this problem often use short technical phrases such as SAML to OIDC, OIDC bridge, SAML OIDC bridge, protocol bridge, protocol translation, SAML to OIDC translation, token translation, identity broker or identity federation broker. The important architecture question is the same: how can an application trust a modern OpenID Connect contract while an existing identity provider, partner or legacy SAML application keeps using the protocol it already supports?
This is more than changing one token format into another. A useful bridge must preserve the intended identity, authentication assurance and application contract across two standards with different message formats, signing models, session behaviour and claim conventions.
When protocol bridging is the right pattern
Protocol bridging is valuable when it creates a controlled boundary between systems that need to change at different speeds.
Typical situations include:
- A new web, mobile or single-page application supports OpenID Connect, but customers or partners authenticate through SAML 2.0 identity providers.
- Existing SAML 2.0 applications need to use a modern OpenID Connect identity provider.
- An organisation is replacing AD FS or another federation platform gradually, for example an AD FS to OpenID Connect migration, rather than changing every application at once.
- Several applications should trust one identity layer even though the external identity providers use different protocols.
- A migration needs parallel test and production environments with a clear rollback path.
If both sides already support the same suitable protocol and can be connected safely, a bridge may add no value. Use it when it reduces coupling or enables a staged change, not merely because protocol translation is possible.
Decide early whether the bridge is a migration stage or a long-lived architecture component. A transitional bridge needs explicit exit criteria for removing the old trust relationship. A long-lived bridge needs named operational ownership, monitoring and certificate lifecycle management on both sides.
Choose the application-facing contract first
The application-facing protocol should normally follow the application's architecture and long-term direction. New applications commonly use OpenID Connect for sign-in and OAuth 2.0 for API access. Existing enterprise applications may need to remain on SAML 2.0 while they are supported or replaced.
With FoxIDs, the application is registered using the protocol it consumes. The external identity provider is configured as an authentication method using the protocol it offers. FoxIDs sits at the trust boundary between them:
SAML 2.0 identity provider → FoxIDs → OpenID Connect application
The reverse direction is also possible:
OpenID Connect identity provider → FoxIDs → SAML 2.0 application
This separation lets application teams standardise on one application contract without requiring every external identity provider to change at the same time.
Preserve identity semantics, not just claim names
SAML assertions and OpenID Connect tokens represent identity differently. A direct name-to-name mapping is rarely enough for a production design.
Define the application contract explicitly:
- Which identifier is stable for the same person across sessions and identity providers?
- Which claims are required for display, authorisation and audit?
- How are groups and roles represented, filtered and transformed?
- Which issuer and audience does the application trust?
- What happens when an upstream provider omits a required claim?
- Can identities from multiple providers be correlated safely, or must they remain separate?
FoxIDs uses JWT claims internally and can map SAML claim types to the shorter claim names commonly used in OpenID Connect. This claims mapping can also transform values before they reach the application. Keep the mapping deliberately small: issue the claims the application needs rather than copying every upstream attribute into each token.
Stable identifiers need particular care. Email addresses and user names can change and are usually poor primary keys. Prefer an immutable source identifier combined with a clearly defined issuer or another identifier whose lifecycle is controlled.
Follow one identity across the bridge
Consider a partner user who signs in through a SAML 2.0 identity provider while the application uses OpenID Connect:
- The SAML assertion supplies an immutable
NameID, an email address, group membership and an authentication context. - FoxIDs validates the signature, issuer, audience and lifetime, then maps the stable source identifier to
sub, selected groups to application roles and the accepted authentication context toacr. - The application receives only its agreed OpenID Connect claims and validates FoxIDs as the issuer.
The application does not need partner-specific SAML logic. When another partner identity provider is added, its claims and assurance signals are normalised at the FoxIDs boundary without changing the application's token contract.
Carry authentication assurance deliberately
A successful SAML sign-in does not automatically tell an OpenID Connect application whether MFA was used or which assurance requirements were met.
Review how the SAML authentication context maps to the OpenID Connect authentication context and acr values expected by the application. Decide whether FoxIDs can accept the upstream assurance, must ask the external identity provider for a stronger authentication step, or should reject the sign-in when the required context is missing.
The same principle applies in the other direction. A SAML 2.0 application may expect a particular authentication context even when the user signs in through an OpenID Connect identity provider.
Do not infer strong authentication from the presence of an external identity provider session alone. Evaluate the returned authentication context against the configured assurance rules and test both successful and rejected paths.
Distinguish login sessions from logout state
OpenID Connect and SAML 2.0 have different session and logout mechanisms. The external identity provider and the application maintain their respective login sessions. FoxIDs does not maintain a third user login session between them; it retains only the session-related information required to coordinate logout.
During sign-in, reauthentication and step-up, FoxIDs sends an authentication request to the external identity provider. It does not reuse its logout-related state as a login session. The external identity provider decides from its own session and the request requirements whether the user can continue without interaction or must authenticate again.
FoxIDs can use the stored logout information to coordinate logout across the relevant relationships. End-to-end single logout may work when every participant supports compatible logout flows and the browser can reach each endpoint, but it should not be assumed. Test front-channel redirects, expired external sessions, partial logout, multiple applications and provider-initiated logout where it is required.
Align application and token lifetimes with the expected external identity provider session behaviour. Ending the application session does not necessarily end the external session, while reauthentication and step-up requirements must be carried in a new request and verified through the returned authentication context.
Plan a staged SAML to OpenID Connect migration
A controlled migration keeps the bridge, application contract and rollback path visible.
- Inventory the current relationships. Record applications, identity providers, metadata, certificates, endpoints, claims, identifiers, MFA requirements, session behaviour and owners.
- Define the target contract. Decide which applications will use OpenID Connect, which SAML 2.0 relationships remain, and which claims and assurance signals must cross the bridge.
- Configure both trust relationships. Add the external provider as a FoxIDs authentication method and the application as a FoxIDs application registration.
- Test failure paths as well as sign-in. Include invalid signatures, wrong issuer or audience, missing claims, expired assertions, replay protection, clock differences, logout and certificate rollover.
- Run in a separate environment. Validate the integration without changing production traffic, then promote the reviewed configuration through controlled environments.
- Move a limited audience first. Use a pilot application, partner or user group and keep the previous route available until the new path is proven.
- Observe and complete the cut-over. Monitor authentication errors, claim differences and support cases before removing the old trust relationship.
FoxIDs tenants can contain separate environments for development, test, migration and production. That supports parallel validation and staged cut-over, but it does not replace a rollback plan or application-level testing.
Require production evidence before cut-over
The bridge becomes part of the authentication path and must be operated as a security boundary. Agree the evidence for each production decision rather than treating a successful sign-in as acceptance.
| Decision area | Evidence required before production |
|---|---|
| Trust endpoints | Named owners, reviewed metadata and restrictions for issuer, audience, recipient and redirect URIs |
| Credentials | Separate controlled keys, accepted algorithms, a certificate rollover test and an owner for renewal |
| Identity contract | A stable subject, a claims allow-list, documented transformations and defined behaviour when required claims are missing |
| Authentication assurance | Accepted upstream contexts, additional MFA rules and tested rejection paths |
| Sign-in and logout | Tested forwarding of sign-in, reauthentication and step-up requests, plus logout, partial logout and the relevant token and external session lifetimes |
| Failure and operations | Tests for invalid, expired and replayed messages, plus audit logs, alerts, support ownership and a rollback decision |
Avoid copying private keys between systems merely to simplify a migration. Give each trust relationship its own controlled credentials and plan rotation before certificates expire.
How FoxIDs supports the bridge
FoxIDs implements protocol bridging through its normal application and authentication method model. There is no separate bridge service to deploy. An OpenID Connect application can use SAML 2.0, OpenID Connect or WS-Federation authentication methods, and a SAML 2.0 application can use those same external sources.
This gives application teams one FoxIDs identity provider contract while identity providers, partners and legacy systems can be connected through the standards they support. FoxIDs also provides claims mapping, configurable authentication flows, MFA and separate environments for testing and production.
Use the protocol bridge documentation for the exact configuration model, authentication methods and application registrations. If the work includes application onboarding, claim design, testing or staged migration, FoxIDs Identity Integration describes the implementation support available from the team behind the platform.
Conclusion
A SAML to OpenID Connect bridge is most useful when it lets applications and identity providers evolve independently without weakening the identity contract between them.
Treat the bridge as a deliberate trust boundary, not an invisible token translator. When the application contract, assurance rules, session behaviour, production evidence, ownership and rollback are explicit, FoxIDs provides the standards-based implementation model for introducing the change in controlled stages.