fix(core): use prefix matching for OAuth resource validation by vrv · Pull Request #17431 · google-gemini/gemini-cli

vrv · 2026-01-24T06:08:14Z

Summary

Use prefix matching instead of exact matching for OAuth protected resource validation, aligning with the MCP TypeScript SDK approach.

This allows servers that advertise a base resource URL (e.g., https://example.com) to be used with endpoints at sub-paths (e.g., https://example.com/mcp).

Details

It appears as though most MCP servers do not implement the OAuth protected resource spec faithfully, returning https://mcp.foo.com for a URL that is https://mcp.foo.com/mcp. The strict checking that is spec compliant unfortunately makes most servers like notion, stripe, etc all not work.

So this implements the same logic as https://github.com/modelcontextprotocol/typescript-sdk/blob/b2326afea6de1104b89a045c5651790490cc8cc8/packages/core/src/shared/authUtils.ts#L26

which does a prefix matching.

Related Issues

Fixes #15754

How to Validate

Try to connect to https://mcp.notion.com/mcp via mcp -- it should complete the oauth process.

Pre-Merge Checklist

Use prefix matching instead of exact matching for OAuth protected resource validation, aligning with the MCP TypeScript SDK approach. This allows servers that advertise a base resource URL (e.g., https://example.com) to be used with endpoints at sub-paths (e.g., https://example.com/mcp).

gemini-code-assist · 2026-01-24T06:08:31Z

Summary of Changes

Hello @vrv, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refactors the OAuth protected resource validation mechanism to use prefix matching instead of exact URL matching. This change aligns the validation behavior with the MCP TypeScript SDK, enabling servers that advertise a general base URL to be correctly validated against more specific sub-path endpoints. The update improves flexibility and compatibility for OAuth resource discovery.

Highlights

Prefix Matching for OAuth Resource Validation: The OAuth protected resource validation now uses prefix matching instead of strict equality, allowing base resource URLs to cover sub-path endpoints.
New Utility Function checkResourceAllowed: A new private helper function checkResourceAllowed has been introduced to perform URL validation, ensuring origins match and the requested path starts with the configured path.
Updated OAuth Configuration Discovery: The discoverOAuthConfig method and other validation points within OAuthUtils have been updated to utilize the new prefix matching logic.
Enhanced Test Coverage: A new test case has been added to verify successful OAuth configuration discovery when the resource metadata specifies a parent path of the server URL.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

gemini-code-assist

Code Review

This pull request switches from exact matching to prefix matching for OAuth protected resource validation. While this is a good feature, the current implementation of the prefix matching in checkResourceAllowed has a critical security vulnerability. It allows for partial prefix matches on URL path segments, which could lead to improper authorization. I have provided a detailed comment and a code suggestion to fix this vulnerability by ensuring the matching is done on full path segments.

gemini-code-assist · 2026-01-24T06:10:23Z

+  // Check if requested path starts with configured path
+  // Add trailing slashes to avoid "/api123" matching "/api"
+  const requestedPath = requested.pathname.endsWith('/')
+    ? requested.pathname
+    : requested.pathname + '/';
+  const configuredPath = configured.pathname.endsWith('/')
+    ? configured.pathname
+    : configured.pathname + '/';
+
+  return requestedPath.startsWith(configuredPath);


The current implementation for prefix matching has a security flaw. It incorrectly allows partial prefix matches on path segments. For example, a configured resource of https://example.com/api would incorrectly allow a requested resource of https://example.com/api-v2. This happens because after appending trailing slashes, "/api-v2/" starts with "/api/".

This can lead to security vulnerabilities if different paths on the same origin have different security policies (e.g., api and api-v2 are different services).

The validation should ensure that it matches full path segments. A requested path should be considered within scope if it's an exact match, or if it's a sub-path (i.e., the configured path is a prefix and is followed by a /).

I've suggested a more robust implementation that correctly handles path segment boundaries.

// Check if requested path is a valid subpath of the configured path. const requestedPath = requested.pathname; const configuredPath = configured.pathname; if (!requestedPath.startsWith(configuredPath)) { return false; } // Exact match is always allowed. if (requestedPath.length === configuredPath.length) { return true; } // If configured path ends with '/', it's a directory-like prefix. if (configuredPath.endsWith('/')) { return true; } // If configured path does not end with '/', the next character in the // requested path must be a '/' to be a valid subpath. This prevents // partial matches like '/api' matching '/api-v2'. return requestedPath.charAt(configuredPath.length) === '/';

This happens because after appending trailing slashes, "/api-v2/" starts with "/api/".

No.

vrv · 2026-01-24T06:24:01Z

@galz10 probably want to review this too -- I think the previous code was doing the spec compliant thing but I think most MCP implementations do something like this. I pointed at one example of the typescript mcp sdk but we can look at others as well.

I tested just now again with notion, my servers, etc., and HEAD was broken, and with this change I can connect to both. Feel free to test / fix / update / advise as you see fit though.

vrv · 2026-01-24T06:26:37Z

https://github.com/modelcontextprotocol/python-sdk/blob/a7ddfdae0721d5c78b35c7810fc4b1a6303538b9/src/mcp/shared/auth_utils.py#L31 also does the same thing

gemini-cli · 2026-01-24T16:44:44Z

Hi there! Thank you for your contribution to Gemini CLI.

To improve our contribution process and better track changes, we now require all pull requests to be associated with an existing issue, as announced in our recent discussion and as detailed in our CONTRIBUTING.md.

This pull request is being closed because it is not currently linked to an issue. You can easily reopen this PR once you have linked it to an issue.

How to link an issue:
Add a keyword followed by the issue number (e.g., Fixes #123) in the description of your pull request. For more details, see the GitHub Documentation.

Thank you for your understanding and for being a part of our community!

vrv · 2026-01-26T02:39:39Z

I've linked it to an issue but I can't reopen it, fyi.

vrv · 2026-02-10T19:18:09Z

Friendly ping for @galz10 !

jgoldringatb · 2026-02-26T18:35:04Z

Any chance this will be re-opened? This does indeed fix the problem, I applied locally and confirmed against the official Gitlab MCP server. v0.30.0 currently yields: Failed to authenticate with MCP server 'Gitlab': Protected resource https://gitlab.com/api/v4/mcp does not match expected https://gitlab.com/api/v4/mcp

vrv · 2026-02-27T21:18:37Z

thanks for confirming! maybe it'd work better if i just re-opened a new one with the exact same fix...

if someone gets to it before i do, please go ahead, just leave a mention that you did it first

vrv requested a review from a team as a code owner January 24, 2026 06:08

gemini-code-assist Bot reviewed Jan 24, 2026

View reviewed changes

gemini-cli Bot added priority/p1 Important and should be addressed in the near term. area/security Issues related to security 🔒 maintainer only ⛔ Do not contribute. Internal roadmap item. labels Jan 24, 2026

test: add test for partial path segment matching

9a19249

gemini-cli Bot closed this Jan 24, 2026

vrv mentioned this pull request Feb 12, 2026

OAuth Protected Resource Metadata Discovery Not Following RFC 9728 §3.1 #15754

Closed

sripasg added the size/m A medium sized PR label Jun 2, 2026

Navigation Menu

Uh oh!

fix(core): use prefix matching for OAuth resource validation - #17431

fix(core): use prefix matching for OAuth resource validation#17431
vrv wants to merge 2 commits into
google-gemini:mainfrom
vrv:fix/oauth-resource-prefix-matching

vrv commented Jan 24, 2026 •

edited

Loading

Uh oh!

gemini-code-assist Bot commented Jan 24, 2026

Uh oh!

gemini-code-assist Bot left a comment

Uh oh!

gemini-code-assist Bot Jan 24, 2026

Uh oh!

vrv Jan 24, 2026

Uh oh!

vrv commented Jan 24, 2026

Uh oh!

vrv commented Jan 24, 2026

Uh oh!

gemini-cli Bot commented Jan 24, 2026

Uh oh!

vrv commented Jan 26, 2026

Uh oh!

vrv commented Feb 10, 2026

Uh oh!

jgoldringatb commented Feb 26, 2026

Uh oh!

vrv commented Feb 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

vrv commented Jan 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Details

Related Issues

How to Validate

Pre-Merge Checklist

Uh oh!

gemini-code-assist Bot commented Jan 24, 2026

Summary of Changes

Highlights

Footnotes

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist Bot Jan 24, 2026

Choose a reason for hiding this comment

Uh oh!

vrv Jan 24, 2026

Choose a reason for hiding this comment

Uh oh!

vrv commented Jan 24, 2026

Uh oh!

vrv commented Jan 24, 2026

Uh oh!

gemini-cli Bot commented Jan 24, 2026

Uh oh!

vrv commented Jan 26, 2026

Uh oh!

vrv commented Feb 10, 2026

Uh oh!

jgoldringatb commented Feb 26, 2026

Uh oh!

vrv commented Feb 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

vrv commented Jan 24, 2026 •

edited

Loading