OAuth Redirect URI Policy Checker

OAuth client label:

Use a short label that will make exported evidence easy to map to the client configuration.

Client profile:

Choose the registration style closest to this client before reviewing redirect URI evidence.

Registered redirect URIs:

Use the exact values from the app registration. Wildcards, fragments, broad localhost use, and nested redirects are flagged.

Keep line breaks: exact string differences are meaningful for redirect URI matching.

Observed redirect_uri values:

Paste one requested redirect_uri per line, or paste full authorization URLs that contain a redirect_uri parameter.

Input review

{{ warning }}

Require exact string matching

Leave on for production review. The checker still reports near matches as drift instead of silently accepting them.

Allow native loopback port variance

Use for native-app loopback redirects where the authorization server supports variable local ports.

Treat wildcard patterns strictly

Flags wildcard hosts, wildcard paths, and broad pattern syntax as production policy findings.

Flag nested redirect parameters

Checks registered callbacks for redirect_uri, next, return_url, continue, and similar parameters that can signal open-redirect chaining.

Source	Redirect URI	Scheme and host	Policy status	Signal	Copy
{{ row.source }}	{{ row.uri }}	{{ row.schemeHost }}	{{ row.status }}	{{ row.signal }}

Severity	Category	Signal	Evidence	Recommendation	Copy
{{ row.severityLabel }}	{{ row.categoryLabel }}	{{ row.signal }}	{{ row.evidence }}	{{ row.recommendation }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Every OAuth authorization-code flow has a handoff point where the browser leaves the authorization server and returns to the client application. That destination is the redirect URI. It receives the authorization response, so it becomes a practical security boundary rather than just another route in the application.

A redirect URI is not the same as a login page, homepage, or loose post-login return target. It is a specific callback address approved in the client registration. The authorization server compares the requested callback against that approved list before sending the browser back with an authorization code, token response, or error. When the approved list is broader than necessary, an attacker has more room to place a lookalike destination, abuse an unreviewed subdomain, or chain through a callback route that forwards the browser again.

Registered redirect URI: The callback value approved on the authorization server for a specific OAuth client.
Observed redirect_uri: The callback value seen in a real authorization request, browser trace, proxy log, or copied authorization URL.
Exact match: The registered value and the requested value are the same string for the parts that matter to the authorization server.
Open redirect: A route that accepts another destination and forwards the browser there, often through parameters such as next, return, or redirect_uri.

Small string differences are enough to matter. A changed trailing slash, default port, encoded query value, wildcard host, fragment marker, or generic private scheme can move a callback from a reviewed route to an unreviewed route. Narrow registrations keep that destination space small, while exact comparison helps expose drift between the app code and the identity-provider configuration.

Scheme and host decide whether the response travels to the expected origin, and production web callbacks normally need HTTPS.
Path and query distinguish the dedicated callback route from general application routes and post-login return handling.
Wildcards widen the approved destination space and can accidentally include tenants, test hosts, or paths that were never reviewed.
Fragments do not participate in normal server-side URI matching and should not be part of an OAuth redirection endpoint URI.

Native applications need extra care because they are public clients and often receive the authorization response through the operating system instead of a conventional web callback. Loopback redirects can use a temporary local port, and private URI schemes should be specific to an app-owned domain name. Those native-app exceptions do not make broad web callback patterns safe.

OAuth redirect URI comparison from authorization request to registered callback and risk signals.

Common OAuth redirect URI policy situations and review concern
Situation	Why it matters
Release changes the callback path	The application may send a different requested value than the one approved in the client registration.
Wildcard host or path is accepted	Unreviewed subdomains, paths, or tenant spaces may become valid redirect targets.
Callback contains a return target	A trusted callback route can become a step in an open redirect chain after authorization.
Native app uses loopback	The local port can vary, but the exception should stay tied to native public clients.

A clean redirect URI review is not the same as a complete OAuth review. Redirect policy reduces the chance that the authorization response is sent to the wrong destination, while state validation, Proof Key for Code Exchange (PKCE), token handling, client authentication, and callback route behavior still need separate checks.

How to Use This Tool:

Review one OAuth client at a time so the evidence, score, and recommendations stay tied to one app registration.

Enter an OAuth client label that matches the app, tenant, or environment under review, then choose the closest Client profile. Use the native profiles only for native apps that intentionally receive the authorization response through loopback or a private URI scheme.
Paste the configured values into Registered redirect URIs. One URI per line works, and copied JSON lists can also be parsed when they contain redirect, callback, or reply URL values.
Add real request evidence in Observed redirect_uri values when you have it. Full authorization URLs are accepted; the input review message will tell you when a redirect_uri value was extracted before matching.
Keep Require exact string matching, Treat wildcard patterns strictly, and Flag nested redirect parameters enabled for production checks. Enable loopback port variance only when the selected profile is a native loopback client.
Loopback port variance changes only the native loopback match path; it does not excuse path, host, scheme, query, or wildcard drift.
Resolve any Input review warning before relying on the result. Invalid URI syntax, missing observed samples, or extracted request values change what the ledger can prove.
Read Redirect URI Ledger first to confirm each parsed value, then use Policy Findings as the repair list. Use Redirect Risk Profile for a category summary after the individual findings make sense.

The safer and risky samples are useful when you want to confirm how exact matches, fragments, HTTP callbacks, wildcard patterns, loopback exceptions, and nested return targets appear in the output.

Interpreting Results:

Start with the highest severity in Policy Findings, not the score alone. One high-severity finding such as an unregistered observed value, a fragment, non-HTTPS web callback, strict wildcard, or external nested redirect can be enough to stop an approval even when the total score is not critical.

OAuth redirect URI result outputs and interpretation cues
Output cue	What it means	Follow-up check
Exact match	The observed requested callback is the same value as a registered redirect URI.	Confirm the callback route validates state and does not forward authorization material to another destination.
Near match only	The value resembles a registered URI after cleanup, but the literal request is different.	Fix slash, port, query string, or encoding drift instead of depending on normalization.
Loopback port match	A native loopback request matched the registered shape while allowing the local port to vary.	Check that the OAuth client is actually native and that the server permits this exception.
Unregistered	An observed requested callback did not match any supplied registration.	Reject the request or register only the exact callback after ownership and route behavior are reviewed.
Risk score	`>=70` is Critical, `>=45` is High, `>=20` is Moderate, and lower scores are Low.	Use the score to prioritize categories, then fix the row evidence that produced it.

A Low score means the supplied values did not trigger the checked redirect URI rules. It does not prove that the authorization server rejects altered callbacks in production, or that the app handles state, PKCE, tokens, and post-login returns safely.

Technical Details:

OAuth 2.0 treats the redirection endpoint as an absolute URI. The value may include a query component that must be retained when the authorization server adds its own response parameters, but it must not include a fragment. Modern security guidance expects exact string matching against pre-registered redirect URIs, with a narrow exception for native app loopback port numbers.

The main failure pattern is excess destination space. HTTP callbacks on non-loopback hosts expose authorization material on the network. Wildcards can approve hosts or paths that were never reviewed. Private URI schemes can collide if they are too generic. Callback routes that accept another URL, such as a return or next parameter, can convert a valid redirect URI into the first step of an open redirect chain.

Rule Core

OAuth redirect URI policy rules and severity weights
Rule family	Finding examples	Default weight
Syntax and structure	Invalid absolute URI, fragment, embedded userinfo, traversal-like path encoding, duplicate registration, or broad root path.	High, medium, or low depending on the specific issue.
Scheme safety	Non-loopback HTTP for web clients, private schemes outside native profiles, or generic private schemes such as a short app name.	High or medium.
Wildcard scope	A host, path, or pattern includes wildcard syntax while strict wildcard review is enabled.	High under strict exact matching, otherwise medium.
Observed request match	Observed value is exact, loopback-port equivalent, near match only, invalid, or unregistered.	High for unregistered or strict near matches; low for accepted loopback port variance.
Nested redirect target	The callback query contains common second-destination names such as redirect, return, next, continue, URL, target, destination, or callback.	High when the value is external, otherwise medium.

Score Construction

The score is a capped sum of non-informational finding weights. Critical findings add 32 points, high findings add 20, medium findings add 10, low findings add 4, and informational findings add 0.

risk score = \min (100, \sum_{i = 1}^{n} w_{i})

In the equation, w is the severity weight for each finding and n is the number of findings included in the assessment. For example, three high findings produce 20 + 20 + 20 = 60, which is a High risk score because it is at least 45 but below 70.

OAuth redirect URI score bands
Score range	Band	Interpretation boundary
`70` to `100`	Critical	Multiple severe redirect-policy failures are present.
`45` to `69`	High	The registration or observed request evidence has enough severe findings to block approval.
`20` to `44`	Moderate	At least one high finding or several smaller findings need review.
`0` to `19`	Low	No checked severe finding is present, or only low-weight notes were found.

Matching Path

Registered values are treated as the approved callback list. Observed evidence can be a raw callback URI, a full authorization URL that contains a redirect_uri parameter, or a copied key-value line. The requested callback is compared with the registered values after parsing, but exact match status still depends on the actual value supplied for the authorization request.

Invalid or blank entries are reported before matching so malformed evidence cannot look clean.
Exact string equality is accepted without adjustment.
Native loopback matching may ignore only the local port when loopback variance is allowed.
Near matches are used as drift evidence, not as silent acceptance, when strict matching is enabled.

Privacy and Accuracy Notes:

The policy comparison runs in the browser from the values you paste into the page; the assessment does not need to send redirect URI lists to a server. Scrub client labels, tenant names, internal hostnames, and callback paths before sharing copied rows, documents, screenshots, or JSON with people who should not see those details.

The result is only as complete as the evidence supplied. It does not test the live authorization server, inspect callback application code, prove ownership of domains, or verify state, PKCE, token storage, client authentication, consent screens, or session handling.

Worked Examples:

Clean production web callback

A confidential web app is registered with https://app.example.com/oauth/callback, and the observed authorization request uses the same value. Redirect URI Ledger shows Exact match, Policy Findings has no actionable finding, and the Risk score is 0/100 in the Low band. The next review step is to test that the callback route validates state and does not forward the response to another target.

Trailing slash drift in release testing

A staging trace shows https://app.example.com/oauth/callback/, while the registered value is https://app.example.com/oauth/callback. With exact matching enabled, Redirect URI Ledger marks the request as Near match only, and Policy Findings records a high match finding. The Risk score becomes 20/100, which is Moderate, until the app request or registration is corrected.

Native desktop loopback port

A desktop app registers http://127.0.0.1:51004/oauth2redirect/provider, then a later authorization attempt uses http://127.0.0.1:62011/oauth2redirect/provider. With Client profile set to native loopback and port variance allowed, the ledger can show Loopback port match. Under strict matching, Policy Findings still adds a low note so the exception is visible in review evidence.

Wildcard plus fragment should block approval

A registered list that includes https://*.example.com/callback, http://app.example.com/oauth/callback, and https://app.example.com/callback#token produces high findings for wildcard scope, non-HTTPS web redirect, and fragment use. Those three findings total 60 points, so the Risk score is High before any observed request drift is considered.

FAQ:

Can I paste a full authorization URL?

Yes. Paste it into Observed redirect_uri values. The checker extracts the requested callback and shows an input review message so you know the value was pulled from a larger request line.

Why does a trailing slash matter?

Exact redirect URI matching treats small string differences as meaningful. A changed slash, port, query string, or encoding can send the authorization response to a different route than the one originally reviewed.

When is localhost acceptable?

Loopback HTTP is meant for native apps and development-style flows where the response stays on the user's device. Production web, browser, and SPA callbacks should use narrow HTTPS redirect URIs instead.

What should I do when a row says Invalid?

Check for relative paths, placeholders, spaces, missing schemes, broken encoding, or copied punctuation. The registered list should contain absolute redirect URIs, and observed evidence should resolve to an actual requested callback.

Does a Low score mean the OAuth client is safe?

No. A Low score means the pasted redirect URI evidence passed the checked rules. Test provider enforcement and review state validation, PKCE, token handling, callback code, and post-login return behavior separately.

Glossary:

Redirect URI: The callback address where the authorization server sends the browser after authorization.
Registered redirect URI: A callback value approved in the OAuth client registration.
Observed redirect_uri: The requested callback captured from an authorization request, trace, log, or copied URL.
Exact string matching: A comparison where the requested callback must match the registered value instead of relying on cleanup or broad patterns.
Native loopback: A native-app redirect pattern that receives the authorization response on a local loopback IP address and often a temporary port.
Open redirect: A route that forwards the browser to a destination controlled by untrusted input.
Fragment: The part of a URI after #, which is not allowed in an OAuth redirection endpoint URI.

References:

RFC 9700: Best Current Practice for OAuth 2.0 Security, IETF and RFC Editor, January 2025.
RFC 6749: The OAuth 2.0 Authorization Framework, IETF and RFC Editor, October 2012.
RFC 8252: OAuth 2.0 for Native Apps, IETF and RFC Editor, October 2017.
Unvalidated Redirects and Forwards Cheat Sheet, OWASP Cheat Sheet Series.