Rely on the official ModelContextProtocol.AspNetCore authentication handler and SessionId

[erwinkramer]

This pull request removes the entire token validation and scope requirement subsystem from the MCPify.Core.Auth namespace. The changes eliminate all code related to access token validation, JWT parsing, scope requirement configuration, and related options and result types. This significantly simplifies the authentication codebase by removing support for validating JWT tokens and checking scope requirements.

The most important changes are:

Removal of token validation system:

• Deleted the IAccessTokenValidator interface, which defined the contract for validating access tokens.
• Removed the JwtAccessTokenValidator implementation, which handled JWT parsing and validation logic.
• Removed the TokenValidationOptions class, which provided configuration for token validation behavior.
• Deleted the TokenValidationResult class, which represented the outcome of token validation.

Removal of scope requirement system:

• Deleted the ScopeRequirement and ScopeRequirementStore classes, which defined and managed per-tool scope requirements and validation logic. [1] [2]

Configuration cleanup:

• Removed references to TokenValidationOptions and ScopeRequirement from the McpifyOptions configuration class, eliminating configuration for token validation and scope requirements.
• Cleaned up using directives in McpifyOptions.cs to remove unnecessary dependencies.

[erwinkramer]

@abdebek let me know what you think. We must leverage as much as possible from the ModelContextProtocol package to keep getting the benefits of it. Or else this project ends up rewriting all functionality in its own way.

Also see https://github.com/modelcontextprotocol/csharp-sdk/blob/main/samples/ProtectedMcpServer/Program.cs for the official sdk implementation

[abdebek]

Thank you so much, @erwinkramer.

I agree that moving to the official ModelContextProtocol.AspNetCore auth handler is the right direction, and it aligns with what we’ve been aiming for.

One thing to clarify: today MCPify includes a login_auth_code_pkce tool plus session storage to support OAuth 2.0 Authorization Code Flow with PKCE for non-browser clients (browser-based consent, code exchange, token persistence/refresh).

With the custom auth subsystem removed, do you expect this functionality to be retained, replaced, or dropped? If replaced, what mechanism would support auth code flow for headless clients going forward?

[erwinkramer]

today MCPify includes a login_auth_code_pkce tool plus session storage to support OAuth 2.0 Authorization Code Flow with PKCE for non-browser clients

Well, it's not part of the mcp spec, but I understand its current use-cases. It still fills a gap that the mcp spec didn't work out yet. Just like machine-to-machine auth.

Even with the changes in this PR, the whole auth-tool setup should still work. If anything, I'd make it separate from this project and move it to MCPify.Extensions or something like that. So, you have 1 library that follows the official spec (and sdk), and 1 library that extends on it in an experimental (non-standardized) matter.

[abdebek]

today MCPify includes a login_auth_code_pkce tool plus session storage to support OAuth 2.0 Authorization Code Flow with PKCE for non-browser clients

Well, it's not part of the mcp spec, but I understand its current use-cases. It still fills a gap that the mcp spec didn't work out yet. Just like machine-to-machine auth.

Even with the changes in this PR, the whole auth-tool setup should still work. If anything, I'd make it separate from this project and move it to MCPify.Extensions or something like that. So, you have 1 library that follows the official spec (and sdk), and 1 library that extends on it in an experimental (non-standardized) matter.

Agreed. Ideally, we shouldn't need anything like MCPify.Extensions, but that would still be cleaner. By the way, I saw your last commit after my earlier comment; I really like the way you setup the sessionId. Good job!

[abdebek]

@erwinkramer, thank you once again. Next, we'll strip out the login tool and make it even cleaner: less maintenance overhead, better reliability and security.