Repository navigation
Add conformance tests for authorization baseline #116
Description
Similar to #78 but even simpler, there are a number of baseline expectations that we could check without even needing a mock AS in the mix. A protected server (remote server requiring authorization) MUST always:
- Reject requests with a malformed
Authorizationheader, e.g.Authorization: foo(https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#token-requirements) - Reject requests with a well-formed
Authorizationheader but a garbage access token, e.g.Authorization: Bearer foo(https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#token-handling)
And some smoke tests for poor JWT implementations - not all access tokens are JWTs, but they are common enough that these footguns are well-documented:
- Reject requests containing an unsigned JWT (no signature part)
- Reject requests containing a JWT with
alg: "none"(an old trick to get around signature validation, should be rejected by all modern JWT libs) - Reject requests containing a self-signed JWT (the presence of a signature is not enough, it must be signed with a trusted key!)
Activity
nbarbettini commentedon Jan 22, 2026
@pcarleton If you think these are a good idea, I can knock them out!
pcarleton commentedon Jan 23, 2026
These sound like reasonable tests, but I think we'd still want them in a setup with an AS? (either the fake one or dev provided).
As in, for rejecting garbage access tokens, you need a server that's got auth enabled, and if you've got auth enabled, then you need a mechanism for checking if a token is any good, which means either DIY or checking with an AS. It's not a good idea, but an AS could say
foois a valid token.To put it another way, I'm trying to imagine an SDK implementation of this, and what they'd do to make it pass. I think what we'd want them to do is use the AS's provided tools for validating things, so either using a public key to validate the jwt, or using an introspection endpoint. And if they're doing that, seems like you want an AS that's dictating the behavior.
A test that could be interesting is providing just the public key, and having the server validate that, but that's sort of mandating that SDK's support a particular flavor of auth, and JWT support isn't required.
Right now the fake AS uses an endpoint, but it would be good if it used JWT's also, so SDK's could implement either route and still pass. (e.g. fetch the jwks at startup and use that to validate instead of introspect).
If you wanted to branch this off the fake AS PR, I'd be down. I'm waiting to merge that one until after a release today because today's release will be the first batch for tiering, and I don't think that test has had enough tire-kicking yet.
Exclude sep-2207 server offline_access guidance until RS auth scenari…
chore: refresh SEP traceability manifest after SEP-2322 (#188) (#301)