How should security teams implement exact redirect URI matching in OIDC and SAML?

Why exact matching matters in OIDC and SAML

Exact redirect URI matching removes ambiguity from the trust boundary. In OIDC, the redirect URI is part of the client registration and the authorization response flow, so the application must compare the incoming value against the stored value byte for byte, not by prefix, wildcard, or loose normalisation. The same principle applies to SAML ACS handling, where recipient and destination checks should be strict.

That strictness is not just a coding preference, it is what prevents an attacker from steering a legitimate authentication response to a different endpoint on the same domain, a sibling path, or a lookalike callback route. For teams standardising federation behaviour, NHIMG’s OAuth 2.0 and OpenID Connect Guide for Identity Teams is the most direct companion for redirect URI handling, while the protocol-level baseline is defined in OpenID Connect Core 1.0.

In practice, exact matching should cover the full callback URL, including scheme, host, path, and any trailing slash semantics the application has chosen to register. If your platform or IdP performs URL canonicalisation, make sure it does not silently widen acceptance, because the security property is lost the moment the server accepts more than one effective destination for the same client registration.

How teams should enforce callback and assertion destination checks

The safest implementation pattern is to store the allowed redirect URI, ACS URL, and related destination fields as fixed values and compare inbound requests against that exact record before issuing or accepting a response. In OIDC, that means the authorization request, token exchange, and client registration policy should all agree on the same callback value. In SAML, the ACS URL, recipient, and destination conditions should be checked with the same level of precision.

This is also where federation hygiene matters. If different environments, tenants, or apps share similar callback structures, use separate registrations rather than trying to make one registration flexible enough to cover them all. The SAML Security Guide is useful when you need the surrounding SAML controls that make strict assertion validation effective, and the OAuth 2.0 Security Best Current Practice Guide is the clearest operational reference for exact redirect URI matching in OAuth-based flows.

Where possible, treat the redirect URI or ACS URL as a deployment-time control, not a runtime negotiation point. That means no user-supplied redirect values, no dynamic fallback to a default callback, and no acceptance of “close enough” values because they look operationally convenient.

What usually goes wrong when matching is too loose

Loose matching creates callback ambiguity, which attackers can exploit to capture authorization codes, tokens, or assertion-bearing responses. A common failure mode is allowing prefix matches, so a malicious path under the same host becomes an acceptable destination. Another is allowing query-string or path rewriting that changes the effective target after registration has been approved.

In SAML, the equivalent mistake is accepting assertions when the recipient or ACS destination is merely similar to the configured value rather than identical to it. That weakens the trust guarantee the service provider relies on, because the response can be replayed or delivered to a location the application did not intend to trust. For an overview of the broader federation attack surface, Identity Provider and SSO Security Guide and the SAML vs OIDC Guide help teams see where callback validation sits in the wider login design.

Risk and Threat Considerations

Loose redirect matching and weak SAML destination validation create a direct path from authentication flow abuse to token or assertion theft. The exposure is highest when the application accepts multiple equivalent-looking callback URLs, because the attacker only needs one permitted variant to turn a legitimate login into a credential-bearing redirect.

Failure mechanism: The verifier accepts a request because it matches by prefix, host only, or normalised path rather than an exact registered value, which lets an attacker route responses to an unintended endpoint.

Impact: Authorization codes, ID tokens, or SAML assertions can be delivered to a malicious or attacker-controlled endpoint, enabling account takeover, session hijack, or federation abuse.

Practitioner Guidance

What to verify: Confirm that every registered callback, ACS URL, and recipient value is stored as an exact allowlisted string and tested against real request samples, not just unit-test fixtures. Verify that the IdP, SP, or application framework does not add permissive canonicalisation behind the scenes.

Common mistake: Teams often secure the obvious login page but leave callback handling to framework defaults, reverse-proxy rewrites, or environment-specific exceptions. That is where the bypass usually appears.

Decision rule: If a redirect or assertion destination can vary at runtime, treat that as a design defect unless there is a narrowly controlled and explicitly reviewed reason for the variation.

Practitioner takeaway: Exact matching is not a nicety, it is the control that keeps federation responses bound to the one destination the trust relationship was actually built for.

Related resources from NHI Mgmt Group

• How should security teams implement exact data matching in DLP for cloud and SaaS environments?
• Why do PKCE and exact redirect URI matching reduce OAuth abuse?
• How should security teams plan a SAML to OIDC migration?
• How should security teams choose between SAML and OIDC?