OAuth state parameter for InspectorOAuthClientProvider via reusable generateOAuthState helper

[KKonstantinov]

Motivation and Context

An extension to #615, which adds the state parameter to the newly introduced flow in the InspectorOAuthClientProvider class.

How Has This Been Tested?

Tested via a real MCP server, added unit tests.

Breaking Changes

None

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

[KKonstantinov]

Also added a simple test & renamed a test file that was ending in .ts instead of .test.ts

[cliffhall]

@KKonstantinov Could you please add a more detailed description of the changes and their intent?

I can see that it appears you've refactor/extracted the generateOAuthState function from oauth-state-machine.ts and put it into oauthUtils.ts where it is also now unit tested and accessed by auth.ts in a new state method. But I don't see any calls to that method, so this PR seems like no net change with regard to behavior.

It would be good to understand what the goal is with this and if it is supposed to be fixing a bug (in which case I suspect there's still some code to add) or just a new feature (the state method in auth.ts that could be called by some future code.

[cliffhall]

Should this be get state() ? If not, why wedge it between two explicit getters? Who is calling this?

[KKonstantinov]

No, it's not a get. The location wasn't picked for any particular reason. Have moved it now.

Re. the rationale of the method. No one from this repository is calling it.

The intent of this addition is for the state parameter to be added to the Authorize URL when the user is redirected to the Authorization Server. Have tested this.

Now to the rationale on how it works to deliver what it's intended to deliver:

1. Observe the lines in useConnection.ts, specifically:

inspector/client/src/lib/hooks/useConnection.ts

Lines 318 to 327 in 113b612

	const serverAuthProvider = new InspectorOAuthClientProvider(sseUrl);
	const result = await auth(serverAuthProvider, {
	serverUrl: sseUrl,
	scope: oauthScope,
	});
	return result === "AUTHORIZED";
	}
	return false;

We have implemented an OAuthClientProvider as defined in the @modelcontextprotocol/sdk client.

Then, in useConnection we are calling the auth method exported from the SDK - implementation here. (https://github.com/modelcontextprotocol/typescript-sdk/blob/4d0977bc9169965233120e823c8024e210132ad9/src/client/auth.ts#L33)

https://github.com/modelcontextprotocol/typescript-sdk/blob/4d0977bc9169965233120e823c8024e210132ad9/src/client/auth.ts#L281-L305

The line in the @modelcontextprotocol/sdk client where it specifically checks if our OAuthClientProvider implementation has defined the "state" method and then calls it is:

https://github.com/modelcontextprotocol/typescript-sdk/blob/4d0977bc9169965233120e823c8024e210132ad9/src/client/auth.ts#L412-L414

The outcome is that the state param is included in the authorization URL whenever the OAuthClientProvider has defined such a method.

Hope this clarifies it, let me know if any more detail is needed.

[KKonstantinov]

TL;DR it's a feature and it is being called by the @modelcontextprotocol/sdk client right now and not in some future code.

[olaservo]

Linking to issue: #682

[olaservo]

Thanks, looks good to me 👍

[cliffhall]

LGTM! 👍