{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }} {{ badge.value }}
The review flags invalid syntax, insecure schemes, fragments, wildcards, broad roots, private-scheme issues, and nested redirect targets.
Exact string differences remain meaningful; trimming removes only blank lines and outer whitespace.
Pin JSON when malformed registration exports should block rather than fall back to line parsing.
Use a short review label; it does not change policy results.
Choose the registration style that will receive the authorization response.
Observed values are optional, but registration drift cannot be tested without request evidence.
OAuth Security BCP exact matching remains the acceptance rule in both modes.
This exception applies only to 127.0.0.1 or [::1] redirect URIs on native clients.
Wildcards never count as exact observed matches.
Keep enabled unless the review intentionally excludes callback-route forwarding behavior.
{{ workflowFeedback }}
Leave blank to use the OAuth client label in exported document titles.
PriorityCategorySignalEvidenceNext actionCopy
{{ row.severity }}{{ row.category }}{{ row.signal }}{{ row.evidence }}{{ row.recommendation }}
SourceRedirect URIScheme and hostMatch statusEvidence signalCopy
{{ row.source }}{{ row.uri }}{{ row.scheme_host }}{{ row.policy_status }}{{ row.signal }}
JWT Claims Risk Checker Check JWT headers and claims against issuer, audience, time, algorithm, replay, exposure, and token-profile rules without uploading the token.
CORS Policy Risk Checker Review CORS response headers for unsafe origin trust and credential use, then catch cache or private-network combinations that need priority fixes.
CSP Header Policy Checker Check a Content-Security-Policy header for risky script sources and missing baseline directives, with reporting and rollout blockers explained.
HTTP Security Headers Checker Audit pasted HTTP security headers for browser policy, session protection and exposure risks with local scoring and a prioritized fix order.

The authorization response in an OAuth flow is valuable enough that its browser destination must be chosen before the flow begins. A redirect URI registration defines that destination for one client, and the authorization request supplies the URI it wants to use for the current response.

If the authorization server accepts a loose pattern, an attacker may steer an authorization code or token toward a host, path, or forwarding route the client owner did not intend. Exact string matching keeps the approved destination narrow. Differences that look cosmetic during ordinary browsing, such as a trailing slash, changed port, reordered encoding, or added query string, can be security-relevant during redirect validation.

The callback route needs the same care as the registration. A fixed HTTPS URI can still be dangerous when it immediately accepts a second destination through parameters such as next, return_url, or redirect_uri. That open-redirect pattern can turn an approved callback into a stepping stone to another origin.

  • Web and browser clients normally use a dedicated HTTPS callback with an exact host, path, and query.
  • Native loopback clients can listen on a temporary port at 127.0.0.1 or [::1]; the port is the narrow exception to exact comparison.
  • Native private schemes should use an app-specific reverse-domain name instead of a short generic scheme that another app could also claim.
  • Development callbacks may need local HTTP, but a development profile should not be used to excuse broad production registrations.

Redirect URI review covers only one part of OAuth security. It does not verify Proof Key for Code Exchange (PKCE), state, client authentication, token handling, callback authorization, or provider-side enforcement. A clean URI inventory is necessary evidence, not a compliance verdict.

Use observed authorization requests as well as registration exports whenever possible. A registration can look tidy while deployed code sends a different slash, port, encoding, host, or callback path that the provider rejects or handles unexpectedly.

How to Use This Tool:

Compare the authorization server's approved callbacks with values captured from the client that actually sends authorization requests.

  1. Paste the Registered redirect URIs as one URI per line or as a registration JSON export. Pin the JSON format when malformed JSON must stop the review instead of falling back to line parsing.
  2. Select the Client profile that receives the authorization response. The profile changes loopback, private-scheme, and non-HTTPS findings, but it does not make near matches exact.
  3. Paste observed redirect_uri values or complete authorization-request evidence. The checker can extract the callback from common URL and key-value forms.
  4. Enable native loopback port variance only for an installed app that uses 127.0.0.1 or [::1] with an ephemeral port. Keep wildcard and nested-redirect review enabled unless the audit scope explicitly excludes those risks.
  5. Review high-severity findings and unregistered or near-match rows before using the overall risk band. Confirm every accepted value against the provider and the callback route.

Interpreting Results:

An Exact match is the strongest registration comparison. Near match only means normalization made two URIs resemble each other, but their supplied strings differ. Unregistered means no approved value matched. A Loopback port match applies only to the explicit native loopback exception.

The risk score adds modeled signals; it does not measure exploitability or provider compliance. Read the highest-severity finding, URI ledger, and recommendation before the band. A low band without observed requests means registration drift was never tested.

Provider rejection is safer than silently accepting a near match. If production login fails because of a slash, port, or encoding difference, align the request and the registration rather than widening the approved pattern.

Technical Details:

OAuth Security Best Current Practice requires exact string matching between requested and pre-registered redirect URIs, apart from the native-app loopback port exception. Wildcard patterns are still reviewed as risk signals and never become exact observed matches.

Rule Core

The review first parses absolute URIs, then applies entry-level security rules and finally compares observed values with the registered set.

RuleExact behavior
SyntaxEvery value must be an absolute URI. Fragments, embedded user information, traversal-like path syntax, and duplicate registrations create findings.
Web schemeHTTP on a non-loopback host is High risk, or Medium under the development profile. A host-root callback receives a Low broad-path finding.
Private schemeA non-HTTP scheme outside a native profile is Medium risk. Under the native-scheme profile, a scheme without a dot receives a Medium generic-scheme finding.
WildcardAny URI containing * is High when strict wildcard review is enabled and Medium otherwise. It never satisfies exact matching.
Nested redirectRecognized return-destination parameters produce Medium findings; a value that starts with an HTTP(S) or protocol-relative destination produces High.
Exact comparisonThe supplied observed URI string must equal a supplied registered URI string, including slash, port, query, and encoding.
Near comparisonHTTP(S) comparison lowercases scheme and host, removes a default port, removes trailing slashes, and sorts query pairs. Similarity under that representation is still not acceptance.
Loopback exceptionWhen enabled for the native-loopback profile, only 127.0.0.1 and [::1] may vary the port; scheme, IP literal, path, and query must still match.

localhost is recognized as loopback for scheme review but is not eligible for port-variance matching. It receives a Low finding under the native-loopback profile because a loopback IP literal avoids hostname-resolution ambiguity.

Formula Core

Each finding adds a fixed number of risk points, and the total is capped at 100. Repeated findings can therefore raise the score more than one severe condition alone.

Rscore = min(100,∑inwi)
ItemExact value or boundary
Finding weightsCritical 32, High 20, Medium 10, Low 4, Info 0
LowScore < 20
Moderate20 ≤ score < 45
High45 ≤ score < 70
CriticalScore ≥ 70

Each source accepts up to 200,000 characters, with no more than 200 registered rows and 200 observed rows per review. Registration JSON is searched for common redirect, callback, and reply URI field names; explicit JSON mode stops on malformed input or an export with no recognized URI field.

Privacy and Accuracy Notes:

The comparison runs in the browser and does not contact the authorization server, identity provider, callback host, or any URI found in the input.

  • Authorization URLs and registration exports can contain client identifiers, tenant names, internal hosts, and return destinations. Remove secrets and avoid sharing sensitive evidence unnecessarily.
  • The parser models URI and registration policy. It does not execute redirects, inspect callback code, or test provider acceptance.
  • The score and bands are transparent triage heuristics, not values defined by an OAuth standard.

Worked Examples:

Trailing-slash drift

A registration contains the HTTPS callback at app.example.com/oauth/callback, while an observed request uses the same path with a trailing slash. The values become a near match, not an exact match. The safer correction is to make the request use the registered string or deliberately register the exact route after review.

Native loopback port

A native client registers an HTTP callback at 127.0.0.1:49152/callback and listens on port 51004 for a later run. With the native-loopback profile and port variance enabled, the same callback at 127.0.0.1:51004/callback receives a loopback port match because the IP literal, scheme, path, and query remain unchanged.

References: