How to Add OIDC or SAML Authentication to Nginx: Every Real Option

Here is the fact that sends many teams searching for nginx oidc and nginx saml: stock open-source nginx does not include a turnkey OIDC relying-party feature or a SAML service-provider feature in nginx core. There is no simple directive that turns nginx into a full enterprise identity layer.

That does not mean nginx cannot sit in front of protected applications. It means every production setup chooses an architecture around nginx. Some teams buy NGINX Plus. Some run Lua or an auth sidecar. Some bridge SAML to OIDC. Some put a purpose-built identity-aware access proxy in front.

Part 1: OIDC on nginx

Option 1: NGINX Plus

F5 documents an OpenID Connect configuration path for NGINX Plus, where NGINX Plus participates in the login flow and can validate identity before forwarding requests upstream. See the current F5/NGINX OpenID Connect documentation before building around any specific release capability.

This is the cleanest commercial nginx-native path if you already operate NGINX Plus. The tradeoff is straightforward: licensing, per-instance configuration, and an identity design that still lives close to nginx configuration and release processes.

Option 2: OpenResty with lua-resty-openidc

OpenResty plus lua-resty-openidc is the classic open-source engineering path. Lua handles the OIDC relying-party logic and nginx keeps handling traffic.

It is powerful and flexible, especially for teams that already know OpenResty. It also makes authentication code part of your owned platform: session storage, token validation behavior, dependency updates, configuration review, and incident debugging are all on your team.

Option 3: oauth2-proxy with auth_request

With stock nginx, many teams delegate authentication to oauth2-proxy. Nginx calls oauth2-proxy through `auth_request`, oauth2-proxy performs the OIDC/OAuth flow, and nginx forwards the request when the auth subrequest succeeds. The oauth2-proxy docs describe both provider configuration and nginx integration patterns.

This is a good fit for OIDC-only internal tools when a platform team is comfortable owning the moving parts. Its limits show up when the estate also needs SAML, richer per-path policy, detailed header mapping for legacy apps, or enterprise support. See the dedicated oauth2-proxy alternative comparison for that decision.

Option 4: Datawiza Access Proxy in front

Instead of teaching nginx to become an identity product, you can put Datawiza Access Proxy in front of applications and let nginx keep doing routing, TLS, caching, and app delivery. Datawiza handles OIDC to identity providers such as Microsoft Entra ID, Okta, Ping, Duo, Google, and others; maps claims into trusted headers; applies URL-path-level authorization; supports attribute enrichment from LDAP, SQL, or REST; and provides centralized authentication and access logs for audit and SIEM review.

Datawiza is not the free DIY path. The value is that OIDC, policy, headers, MFA, operations, and support live in a product built for that job instead of becoming app-by-app nginx glue.

Part 2: SAML on nginx

SAML is harder to bolt into stock nginx than OIDC. XML signatures, assertion validation, metadata, certificates, and SAML service-provider behavior do not map cleanly to a tiny nginx directive.

Option 1: NGINX Plus SAML reference implementation

F5/NGINX publishes a SAML single sign-on reference implementation for NGINX Plus. Treat this as an NGINX Plus architecture to evaluate against your current support plan and the current reference code, not as a generic open-source nginx module.

Option 2: Bridge SAML to OIDC

If your identity provider is SAML-only but your nginx-side tooling is OIDC-only, a broker such as Keycloak can translate the identity side. The broker authenticates users against the SAML IdP and exposes OIDC to the component in front of nginx.

This can be fully open source. It also adds a protocol broker, a new operational dependency, more metadata and certificate lifecycle work, and another place to troubleshoot login failures.

Option 3: Datawiza Access Proxy for SAML and OIDC

Datawiza can serve as the application-side proxy for both SAML and OIDC. It validates assertions or tokens from the identity provider, creates an application session, applies policy, and forwards trusted identity to the upstream app. That is why the same product appears in both lists: it is designed for mixed estates where some identity integrations are SAML, some are OIDC, and the applications behind the proxy should not need to care.

For the SAML side in more detail, read What Is a SAML Proxy?.

Choosing the right option

• Already licensed for NGINX Plus and standardizing there: start with the current F5/NGINX OIDC or SAML guidance.
• Already invested in OpenResty and Lua: lua-resty-openidc can be a strong DIY path for OIDC.
• Stock nginx, OIDC-only, small number of internal apps: oauth2-proxy with auth_request is often enough.
• SAML-only identity source and open-source mandate: consider a protocol broker, but budget operational time for it.
• Mixed SAML/OIDC, legacy header apps, path-level policy, MFA, audit, and support requirements: put Datawiza Access Proxy in front.

FAQ

Does open-source nginx support OIDC or SAML natively?

Not as a turnkey enterprise authentication layer in nginx core. Teams use NGINX Plus, Lua/OpenResty, oauth2-proxy with auth_request, a SAML-to-OIDC bridge, or a dedicated access proxy in front.

Can I add OIDC to nginx without NGINX Plus?

Yes. Common options are lua-resty-openidc on OpenResty, oauth2-proxy through nginx auth_request, or a product such as Datawiza Access Proxy in front of the application.

Does oauth2-proxy support SAML?

No. oauth2-proxy is built around OAuth2 and OIDC providers. SAML requires a protocol broker in the chain or a SAML-capable proxy.

Is there one option that handles both SAML and OIDC?

Yes. A dual-protocol identity-aware access proxy can handle both. Datawiza Access Proxy supports SAML and OIDC integrations from the same management model.

Which option adds MFA?

Most options inherit MFA from the identity provider. Datawiza can also enforce built-in MFA at the access layer for applications that are not ready to rely on an external identity provider.

Compare the Options in Your Environment

Want to compare DIY nginx authentication with a managed access proxy? Datawiza can show how SAML, OIDC, MFA, headers, and policy work in front of your existing apps. Book a demo.