{{ summary.heading }}
{{ summary.primary }}
{{ summary.line }}
{{ badge.label }}
Use a short label that will make exported evidence easy to map to the client configuration.
Choose the registration style closest to this client before reviewing redirect URI evidence.
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.
Paste one requested redirect_uri per line, or paste full authorization URLs that contain a redirect_uri parameter.
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 }}
Tags: HTTP, Security
Export to PDF Fullscreen
Customize
Advanced
:

OAuth redirect URI policy is the part of an authorization flow that decides where an authorization server is allowed to send a browser after sign-in or consent. The value looks like an ordinary callback URL, but it protects authorization codes and tokens from being sent to the wrong application, a lookalike host, or a callback that immediately forwards the browser somewhere else.

A strong redirect policy starts with exact registered callbacks. Small differences matter: https://app.example.com/oauth/callback and https://app.example.com/oauth/callback/ can be treated as different values, and a changed port, query string, or encoding can turn a working login test into a security review finding. Native applications have a special loopback pattern because they often listen on a temporary local port, but that exception should not leak into ordinary web app registrations.

OAuth redirect URI policy review flow from registered callbacks to observed requests, policy checks, findings, score, and release review.

Redirect URI review matters during new client registration, single-page app releases, native app setup, identity provider migration, and incident cleanup after a mismatch error. It also matters when a trusted callback accepts a nested return target such as next, continue, or redirect_uri. A callback that passes registration checks but forwards to an attacker-controlled destination can still expose authorization material.

A low-risk redirect policy does not prove the whole OAuth flow is safe. It means the callback strings and observed requests match the checked redirect rules. Client authentication, Proof Key for Code Exchange, state handling, token storage, and endpoint code still need their own review.

Technical Details:

OAuth 2.0 treats a redirection endpoint as an absolute URI. The endpoint may include a query component, but it must not include a fragment component. When a full redirection URI is registered, current security guidance expects exact string matching at the authorization server, with a narrow exception for native loopback ports. That is why slash, port, query, case, and encoding drift need visible review instead of quiet normalization.

Risk increases when callback control becomes broader than the client actually needs. HTTP on a non-loopback host can expose sensitive authorization responses. Wildcards can allow unreviewed subdomains or paths. Private URI schemes make sense for native clients, but generic schemes are easier to collide with than reverse-domain schemes. A nested return target in the callback query can turn a trusted host into an open-redirect step.

Rule Core

The checker parses registered redirect URIs and optional observed authorization-request values, then builds findings from syntax, scheme, exact match status, wildcard scope, fragment use, loopback profile, and nested redirect parameters. Observed lines may be pasted as raw callback URLs, full authorization URLs that contain redirect_uri, key-value snippets, or JSON-style configuration entries.

Review signal Checked rule Typical follow-up
Exact match Observed redirect_uri values are compared against the registered list. Near matches are flagged when only normalization, trailing slash, sorted query, or similar cleanup makes them look alike. Update the request or registration so the callback value matches exactly, including path, port, query string, and encoding.
Scheme safety Non-loopback http callbacks are findings for production-style clients. Private URI schemes are expected only for native client profiles. Use HTTPS for browser, single-page app, and confidential web clients; reserve private schemes for native app registrations.
Native loopback Loopback callbacks are accepted for the native loopback profile, and port variance can be allowed for local ephemeral ports. Use loopback IP literals where possible and keep loopback callbacks out of ordinary web app registrations.
Fragments A registered or observed URI containing a fragment such as #token becomes a high-severity finding. Remove fragments from registered callbacks and keep authorization response handling on the callback route itself.
Wildcard scope Wildcard hosts, paths, or pattern syntax are flagged when strict wildcard review is enabled. Register each callback route that is actually needed instead of approving a broad pattern.
Nested redirects Callback query parameters such as redirect_uri, return_url, next, continue, and similar names are flagged when nested redirect review is enabled. Route to a fixed callback first, then validate any post-login return path separately against an approved application route.

Score and Band Logic

The risk score is a capped sum of finding weights. Informational rows do not add score, while low, medium, high, and critical findings add progressively more weight. The band is based on the total score after capping, so repeated high findings can produce a Critical summary even without a critical-severity row.

risk score = min ( 100 , ∑ finding weight )
Finding or band Weight or boundary How to read it
Critical finding 32 Reserved for the most severe finding type in the scoring model.
High finding 20 Unregistered observed callback, near match under strict matching, invalid syntax, fragment, non-HTTPS web callback, wildcard pattern, or external nested redirect.
Medium finding 10 Profile mismatch, private scheme outside native use, generic private scheme, blank entry, or non-external nested redirect.
Low finding 4 Duplicate registration, broad root path, localhost hostname in a native loopback review, or accepted loopback port variance under strict matching.
Risk band 70+, 45+, 20+, below 20 Total score becomes Critical, High, Moderate, or Low. The findings table remains the authority for what to fix.

Exact matching and port variance are deliberately separate. A native loopback request can match by shape while using a different local port, but the same drift on a web callback should slow the review because it may point to a different route or client registration.

Everyday Use & Decision Guide:

Start with one OAuth client at a time. Enter a short OAuth client label, choose the Client profile, and paste the exact callback values from the authorization server into Registered redirect URIs. If you have browser traces, proxy logs, or authorization URLs from testing, paste those into Observed redirect_uri values so the checker can compare real requests against the registration.

For a production web app, keep Require exact string matching, Treat wildcard patterns strictly, and Flag nested redirect parameters enabled. For a native desktop app that uses a local callback, select Native app with loopback redirect; the loopback port exception is then part of the review instead of being treated like an ordinary web mismatch.

  • Use Load safer sample to see the clean baseline: HTTPS callbacks and observed values that match the registered list.
  • Use Load risky sample to see how wildcard hosts, HTTP callbacks, fragments, nested redirect parameters, loopback profile mismatch, unregistered observed callbacks, and near matches appear.
  • Use Trim lists after copying from a console, ticket, or identity provider page so wrappers and blank lines do not distract from the actual URI values.
  • Read Input review before relying on the score. Invalid URI syntax or extracted observed values can change what the result means.
  • Open Policy Findings before changing registration settings. The evidence and recommendation columns are more actionable than the total score alone.

Do not treat a Low band as approval for the whole client. A Low band means the pasted callbacks did not trigger the checked redirect URI rules, or only low-weight notes remained. Confirm that the identity provider itself rejects unregistered callbacks, that the client uses the intended flow, and that the callback route does not forward authorization material to an unapproved destination.

A useful release note is usually short: client label, profile, summary band, exact observed match count, and any remaining high or medium findings. If the findings table contains an unregistered observed URI, a fragment, or an external nested redirect parameter, fix that before treating the client registration as ready.

Step-by-Step Guide:

Review a single client registration and a single set of observed requests so the ledger, findings, and chart describe the same OAuth flow.

  1. Enter OAuth client label with the app, environment, or registration name you want shown in the summary, such as partner-dashboard production.
  2. Choose Client profile. Use Confidential web app or Browser or SPA public client for HTTPS callbacks, and use Native app with loopback redirect only when the client receives the authorization response on a local loopback port.
  3. Paste the configured values into Registered redirect URIs, one per line. JSON arrays or objects with redirect, callback, or reply URL keys can also be parsed into URI entries.
  4. Paste test evidence into Observed redirect_uri values. Full authorization URLs are accepted when they contain a redirect_uri parameter; the input warning tells you when values were extracted before matching.
  5. Open Advanced and confirm the switches. Leave exact matching and strict wildcard review on for production-style review; use loopback port variance only for native loopback clients.
  6. Fix any Input review warning before trusting the summary. Invalid absolute URI syntax, blank entries, or missing observed values can leave important match checks incomplete.
  7. Read the summary line. A value such as Critical - 100/100 means the score reached the cap; Low - 0/100 means no actionable redirect URI finding was produced from the current entries.
  8. Open Redirect URI Ledger to confirm each row's source, scheme and host, policy status, and row-specific signal.
  9. Open Policy Findings and work from the highest severity down. Use Redirect Risk Profile when you need a quick view of which categories are contributing score.

A clean review has registered callbacks that match the intended client profile, observed values that are exact matches or intentional native loopback matches, and no high or medium findings left in the policy table.

Interpreting Results:

The most important result is the first high or medium row in Policy Findings. The summary score helps triage, but a single unregistered observed callback, fragment, non-HTTPS web callback, or external nested redirect parameter is enough to stop a release review until the registration or callback route is corrected.

Visible cue Best first reading What to verify next
Exact match The observed value matches a registered callback string exactly. Confirm the callback route itself validates state and does not forward authorization material to an unapproved target.
Near match only The observed value resembles a registered URI after normalization but is not the same string. Fix the request or registration so slash, query, port, and encoding agree exactly.
Loopback port match A native loopback callback matched while ignoring the local port. Confirm the selected client profile is a native app and that the authorization server intentionally permits variable loopback ports.
Unregistered The observed callback did not match any registered value. Reject the authorization request or add the exact callback only after ownership and route behavior are reviewed.
Nested redirect parameter The callback contains a parameter name commonly used for a second redirect target. Remove the nested target from the registered callback and validate post-login return paths inside the application.

A clean ledger is not a proof that the identity provider enforces the same rules. Test the real authorization endpoint with a changed callback, such as a trailing slash or unregistered host, and confirm it returns an error instead of redirecting the browser.

Worked Examples:

Production web client with exact callbacks

A web client registers https://app.example.com/oauth/callback and https://admin.example.com/auth/callback. The observed authorization requests use the same two values. With the web profile and strict matching enabled, the summary can read Low - 0/100, 2/2 observed matched, and 0 findings. The useful follow-up is to confirm the identity provider rejects a changed callback, not to loosen the registration.

Risky registration with broad and forwarded callbacks

A registration includes https://*.example.com/callback, http://app.example.com/oauth/callback, a callback with #token, and a callback query containing an external redirect_uri. Observed values also include https://evil.example/callback and a trailing-slash near match. Policy Findings shows high-severity rows across wildcard scope, scheme safety, fragment handling, open redirect, and exact match, and the total can cap at Critical - 100/100.

Native loopback app using a temporary port

A desktop client registers http://127.0.0.1:51004/callback and an observed request uses http://127.0.0.1:61023/callback. Under Native app with loopback redirect, the ledger can show Loopback port match rather than Unregistered. If strict exact matching is enabled, the low finding is still useful because it asks you to confirm that variable loopback ports are intentional.

Troubleshooting a syntax warning

A copied registration contains /oauth/callback instead of an absolute URI. Input review reports that an entry could not be parsed, and Policy Findings adds Invalid redirect URI syntax. Replace the relative path with the full callback, such as https://app.example.com/oauth/callback, then rerun the review before reading the risk band.

FAQ:

Can I paste full authorization URLs?

Yes. In Observed redirect_uri values, a full authorization URL is parsed for its redirect_uri parameter. The input warning tells you when the value was extracted before exact-match comparison.

Why did a trailing slash become a finding?

Strict redirect matching treats the registered and observed strings as security-sensitive values. A trailing slash, different query string, changed port, or different encoding can point to different routing behavior, so a near match is reported instead of silently accepted.

When should loopback port variance be allowed?

Use it for native app loopback redirects, where the app listens on a temporary local port during the authorization flow. Do not use it to excuse port drift on ordinary browser, single-page app, or confidential web clients.

Does a Low score mean the OAuth client is safe?

No. It means the current redirect URI evidence did not trigger the checked policy findings, or only low-weight notes remained. Review state handling, PKCE, token storage, callback route behavior, and identity provider enforcement separately.

Does this send my redirect URI list to a server?

The assessment is computed in the browser from the fields you paste, and the JSON view is built from the current review values. Avoid pasting client secrets or tokens; redirect URI evidence usually does not need them.

Glossary:

Redirect URI
The callback value where the authorization server sends the browser after the authorization step.
Observed redirect_uri
The callback value seen in an authorization request, often copied from a browser trace, proxy log, or full authorization URL.
Exact match
A registered and observed callback string that matches without normalization or inferred cleanup.
Native loopback redirect
A native app callback that uses a local loopback address and may use a temporary port during the flow.
Private URI scheme
A native app callback scheme such as com.example.app: that launches an installed application rather than a web route.
Open redirect
A callback or application route that forwards the browser to a user-controlled destination.

References: