Table of contents
An application-side SAML proxy is a reverse proxy that handles SAML single sign-on for a web application that does not speak SAML itself. It sits in front of the application, acts as the SAML service provider, validates assertions from the enterprise identity provider, creates an authenticated session, and passes a trusted identity to the application.
This pattern is useful when the application already works but cannot be brought into Microsoft Entra ID, Okta, Ping Identity, ADFS, Shibboleth, or another SAML identity provider without a lengthy integration project. The SAML logic lives at the application access layer instead of inside every application.
What an Application-Side SAML Proxy Does
The reverse proxy becomes the trust boundary between the identity provider and the application. It owns the protocol work that the application was never designed to perform:
- SAML service-provider behavior: generate authentication requests, expose an assertion consumer service, and maintain service-provider metadata.
- Assertion validation: verify the signature, issuer, audience, recipient, timestamps, and other SAML conditions before trusting the identity.
- Session management: establish and protect the browser session after successful enterprise authentication.
- Identity translation: map SAML attributes to the username, groups, roles, trusted headers, or signed JWT the application can consume.
- Central policy and audit: apply access rules consistently and record authentication and routing decisions outside the application.
The application can remain focused on its business logic. It does not need to parse SAML XML, manage federation certificates, process assertions, or implement the browser redirect flow.
How the Application-Side SAML Reverse Proxy Works
- The user requests the application. The browser reaches the SAML reverse proxy before it reaches the application origin.
- The proxy starts SAML authentication. Acting as the service provider, it redirects the browser to the configured enterprise IdP with a SAML authentication request.
- The IdP authenticates the user. The identity provider can apply MFA, conditional access, device policy, or other enterprise controls before issuing a signed assertion.
- The proxy validates the assertion. It verifies the signature and SAML conditions, extracts approved identity attributes, and establishes a session.
- The application receives a trusted identity. The proxy forwards approved traffic and supplies the identity through protected headers or a signed JWT, depending on the application's integration model.
How the Existing Web App Receives Identity
Many existing applications already know how to read a username or group from a trusted web server, load balancer, or web access management product. The SAML proxy can preserve that model by translating the SAML assertion into the exact identity format the application expects.
For header-based authentication, the proxy must strip or overwrite identity headers received from the client. The application origin must accept traffic only from the proxy over a protected network path. Otherwise, a client could bypass the proxy and invent an identity header.
A signed JWT provides another option when the application can validate a token but cannot implement the complete SAML protocol. The proxy still performs the SAML exchange, while the application receives a compact identity object it can verify more easily.
SAML Proxy vs. Identity Broker
The term SAML proxy is also used for identity-side brokers that sit between two identity systems. That is a different problem. An identity broker translates or federates protocols between identity providers and relying parties. An application-side SAML reverse proxy sits directly in the application's request path and protects the application itself.
If the identity systems cannot federate with each other, use identity-broker tooling. If the web application is the component that cannot support SAML, use the application-side reverse proxy pattern described here.
When an Application-Side SAML Proxy Is a Good Fit
- Existing or custom web applications that have a working login and session model but no native SAML support.
- Vendor-managed applications that cannot be changed but still need enterprise SSO, MFA, and centralized access policy.
- Header-based applications migrating from SiteMinder, Oracle Access Manager, IBM Security Access Manager, or another web access management product.
- Mixed application estates where some apps need SAML, others use OIDC, and older apps consume identity headers.
- Multiple applications that would otherwise require separate SAML libraries, metadata management, certificate rotation, and policy implementations.
oauth2-proxy SAML Support: Does oauth2-proxy Support SAML?
No, not as a native SAML service provider. The current oauth2-proxy provider documentation lists OAuth 2.0 and OpenID Connect providers. oauth2-proxy can authenticate users through those providers and forward traffic to an upstream application, but it does not directly consume SAML assertions as an application-side SAML SP.
The ADFS provider name can cause confusion. ADFS supports OAuth and OIDC as well as SAML; oauth2-proxy uses its OAuth/OIDC endpoints rather than a SAML assertion flow.
If your identity provider is SAML-only, you can place an identity broker in front that exposes OIDC to oauth2-proxy, or choose a reverse proxy that supports SAML directly. The bridge adds another component and trust relationship, so a native SAML-capable application proxy is usually simpler when SAML is the required enterprise protocol.
For a broader operational comparison, see OAuth2 Proxy Alternative: When and Why Teams Move Beyond oauth2-proxy.
Datawiza Access Proxy as the Application-Side SAML Proxy
Datawiza Access Proxy sits in front of the application and acts as its SAML service provider. It integrates with Microsoft Entra ID, Okta, Ping Identity, ADFS, Shibboleth, and other enterprise IdPs, validates SAML assertions, applies access policy, creates the user session, and passes the approved identity to the application.
The same access layer can also support OIDC connections, which is useful when an organization has a mixed identity and application estate. Each application can continue using its existing downstream identity model while the proxy centralizes SSO, MFA, session policy, and audit records.
Datawiza can run as a hosted service or in a customer's AWS, Azure, Google Cloud, data center, or private environment. The application origin remains under the customer's control, and the deployment can be aligned with existing load balancers, ingress controllers, and network segmentation.
Application-Side SAML Proxy Security Checklist
- Block direct origin access so every protected request passes through the proxy.
- Strip and overwrite identity headers instead of trusting values supplied by the browser.
- Validate every SAML condition including signature, issuer, audience, recipient, time limits, and replay protections.
- Plan certificate rotation for both IdP metadata and service-provider signing or encryption certificates.
- Test session and logout behavior across the IdP, proxy, and application before production cutover.
- Audit attribute mappings and policy so only approved claims become application identities or roles.
Frequently Asked Questions
What is an application-side SAML proxy?
It is a reverse proxy that acts as the SAML service provider for a web application. It handles the SAML exchange, validates the identity, establishes a session, and passes a trusted identity to an application that does not implement SAML itself.
Is a SAML proxy the same as a reverse proxy?
An application-side SAML proxy is a reverse proxy with SAML service-provider behavior. It does more than route traffic: it authenticates the user, validates assertions, manages the session, and enforces access policy before forwarding a request.
Does oauth2-proxy support SAML?
oauth2-proxy does not provide native SAML service-provider support. It is designed for OAuth 2.0 and OIDC providers. A SAML-only IdP therefore requires a SAML-to-OIDC broker or a different proxy that can consume SAML assertions directly.
Can one application proxy support both SAML and OIDC?
Yes. Datawiza Access Proxy can connect applications to SAML and OIDC identity providers from the same access layer, while translating the authenticated identity into the format each application expects.
Can an application-side SAML proxy enforce MFA?
Yes. The enterprise identity provider normally enforces MFA during the SAML authentication flow. The proxy validates the resulting assertion and grants application access only after the required identity policy is satisfied.
Does the application need to implement SAML?
No. The proxy implements the SAML service-provider flow on the application's behalf. The application can continue consuming its existing session, trusted header, or signed-token identity model.
Add SAML SSO at the Application Access Layer
Need SAML SSO and MFA for applications that were never built for SAML? Book a demo to map your identity provider, application session, trusted identity format, and deployment path.
