Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Doc comments misattribute the token-endpoint TLS check to SEP-2207 (which is OIDC refresh / `offline_access`)

Closed Beginner friendly
  • Is something wrong?
#2,766 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
92/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
authentication, documentation

Research direction

Start with the doc comments on assertSecureTokenEndpoint in src/client/auth.ts and InsecureTokenEndpointError in src/client/authErrors.ts. Remove the incorrect SEP-2207 attribution or replace it with the HTTPS requirement source described in the issue, without changing behavior. Done means both comments accurately describe the token-endpoint TLS check and no longer misidentify SEP-2207.

Written by the indexing model from the issue text.

Description

v2
What happened?

The doc comments on assertSecureTokenEndpoint and InsecureTokenEndpointError attribute the token-endpoint TLS check to SEP-2207. That SEP is something else entirely.

modelcontextprotocol#2207 is "SEP-2207: OIDC-Flavored Refresh Token Guidance" — it specifies that clients may add offline_access to the authorization request scope when AS metadata advertises support, and that servers should not echo it. It says nothing about TLS at the token endpoint.

From @modelcontextprotocol/[email protected] (dist/index.mjs, mapping to src/client/auth.ts and src/client/authErrors.ts):

/**
* Thrown by the token-exchange and refresh paths when the resolved token
* endpoint is not `https:` and is not a loopback host (SEP-2207). ...
*/
var InsecureTokenEndpointError = class extends OAuthClientFlowError { ... }

/**
* SEP-2207: refuse to send credentials to a non-TLS, non-loopback token endpoint.
* Throws {@linkcode InsecureTokenEndpointError}. Loopback hosts are exempt.
*/
function assertSecureTokenEndpoint(tokenEndpoint) { ... }
What did you expect?

Either the correct normative citation or none.

The behaviour itself is not in dispute and looks right — the MCP authorization spec requires authorization server endpoints to be served over HTTPS, incorporating OAuth 2.1 §1.5 ("All the OAuth protocol URLs … MUST use the https scheme except for loopback interface redirect URIs"). It is only the SEP number that is wrong.

Why it is worth fixing rather than ignoring

It propagates. We hit this in the MCP Inspector: I took the label from these comments in good faith and carried it into nine files before a reviewer caught it — and it collided badly, because that repo already uses SEP-2207 for its intended meaning (specification/v2_auth_hardening.md, plus a SEP-2207 offline_access on authorize e2e test). Grepping the identifier there returned two unrelated subjects.

A wrong citation in a doc comment is also the kind of thing downstream authors reasonably trust without verifying — it looks like exactly the sort of detail the implementer would have got right.

Suggested fix

Drop the SEP reference from both comments, or replace it with the actual source. Something like:

Refuse to send credentials to a non-TLS, non-loopback token endpoint: the MCP
authorization spec requires AS endpoints over HTTPS (OAuth 2.1 §1.5), with
loopback as the carve-out.

Happy to open the PR if that wording is acceptable — it is a comment-only change.

Note

Unrelated to, but discovered alongside, #2591 (the loopback exemption not covering *.localhost). No behavioural overlap; just the same function.

SDK version

@modelcontextprotocol/[email protected]

Area

Auth

Dominant language
TypeScript
Stars
13.5k
Forks
2.2k
Avg merge
2d 4h
Merged PRs (30d)
45

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from modelcontextprotocol/typescript-sdk

All issues in modelcontextprotocol/typescript-sdk

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.