Cztery poprawki, jedna wspólna nić: mniej zaufania na słowo.
Zmiany w warstwie OAuth dotyczą wyłącznie transportów HTTP (stdio bierze poświadczenia ze środowiska) i są mniejsze niż core, ale każda zamyka realną lukę.
Client ID Metadata Documents zamiast DCR
Dynamic Client Registration (RFC 7591) wymagał, żeby klient „zarejestrował się" u authorization servera zanim cokolwiek zrobi — co jest dziwne w świecie, gdzie klient i serwer MCP często nigdy wcześniej się nie widziały. Client ID Metadata Documents odwracają to: client_id staje się URL-em wskazującym na dokument JSON, który authorization server pobiera na żądanie.
// dostępne pod: https://app.example.com/oauth/client-metadata.json { "client_id": "https://app.example.com/oauth/client-metadata.json", "client_name": "Example MCP Client", "redirect_uris": ["http://127.0.0.1:3000/callback"], "grant_types": ["authorization_code"], "token_endpoint_auth_method": "none" }
Authorization server, widząc client_id w formie URL-a, pobiera ten dokument, waliduje, że client_id w środku zgadza się z URL-em, sprawdza redirect_uris — i tyle, żadnej wcześniejszej rejestracji. Priorytet, jaki klient MUSI stosować: poświadczenia pre-rejestrowane → Client ID Metadata Documents (jeśli AS je wspiera, sygnalizowane przez client_id_metadata_document_supported: true) → DCR jako fallback → prompt do użytkownika.
iss — RFC 9207
Serwer autoryzacji POWINIEN dołączać parametr iss do odpowiedzi autoryzacyjnej. Klient MUSI zwalidować tę wartość względem zapamiętanego wcześniej identyfikatora issuera, zanim wymieni kod na token. To zamyka klasę ataków, w których kod autoryzacyjny wystawiony przez jeden serwer trafia do klienta myślącego, że rozmawia z innym.
application_type w DCR
Jeśli mimo wszystko używasz DCR, a authorization server wspiera OpenID Connect — pominięcie application_type domyślnie ustawia "web", co potrafi się pogryźć z redirect URI w stylu natywnej aplikacji (localhost, custom scheme). Reguła: aplikacje desktopowe/mobilne/CLI/lokalne web → "native"; zdalne aplikacje przeglądarkowe → "web". Serwery bez OIDC bezpiecznie ignorują to pole.
Poświadczenia związane z issuerem
Klient MUSI kluczować zapisane poświadczenia (pre-rejestrowane albo z DCR) po identyfikatorze issuer serwera, który je wystawił. Gdy authorization server się zmieni (wykryte przez protected resource metadata) — klient MUSI się przerejestrować, nie wolno mu użyć starych poświadczeń z innym serwerem.
Client ID Metadata Documents są przenośne między authorization serverami — to samohostowany URL, rozwiązywany na żądanie przez dowolny AS. Migrując serwer autoryzacji, z tym mechanizmem nie musisz nic przerejestrowywać.