Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

[Server] Bind Streamable HTTP sessions to the authenticated principal

Aberta
  • Algo errado?
#529 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
32/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
php
Domínio
api, authentication, backend, security

Direção de pesquisa

Start from Protocol::resolveSession() and StreamableHttpTransport session load/destroy (Mcp-Session-Id, sessionManager exists/createWithId/destroySession) plus AuthorizationMiddleware. The issue wants a stable identity fingerprint stored on initialize and compared on later POST/DELETE (404 on mismatch). Read the linked MCP session-hijacking guidance, then decide with maintainers the open questions (always vs opt-in, Protocol vs store keying, opaque tokens) before coding; done is sessions bound to the principal without accepting another valid token on the same ID.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

Server

Currently a stateful StreamableHttpTransport session is resolved only by its Mcp-Session-Id header - Protocol::resolveSession() checks sessionManager->exists() and loads it with createWithId(), and DELETE goes straight to destroySession(). With AuthorizationMiddleware in front, every request is still authenticated with the caller's own token and scopes are not inherited, but the session doesn't know which principal created it. So a request with a different valid token and the same session ID is accepted into that session, DELETE included.

Session IDs are random UUIDs, so this isn't easy to hit - still, the spec's security best practices say servers SHOULD bind session IDs to user-specific information: https://modelcontextprotocol.io/specification/2025-11-25/basic/security_best_practices#session-hijacking (the draft has the same as "state handle hijacking").

Thanks @GEONWOOHAN for bringing this up.

Rough direction:

  • AuthorizationResult exposes a stable identity - issuer + subject rather than sub alone, maybe the client id as well
  • the transport passes that into session resolution
  • on initialize we store a fingerprint of it in the session, later POST/DELETE compare and answer 404 on mismatch

Open questions:
a) bind always when an identity is present, or opt-in via the builder?
b) does it belong into Protocol or rather the session manager / store, so a custom store can key on <principal>:<session id>?
c) what about validators that don't produce a subject (opaque tokens, API keys)?

Keeping the core unaware of OAuth would be nice, so probably a plain identity string rather than the auth result itself.

WDYT?

Linguagem predominante
PHP
Estrelas
1.6k
Forks
177
Merge médio
3d 1h
PRs com merge (30d)
27

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de modelcontextprotocol/php-sdk

Todas as issues de modelcontextprotocol/php-sdk

Issues semelhantes

Mais issues de PHP

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.