| OAuth 2.1 בשרת ההרשאותbasic/authorization | “Authorization servers MUST implement OAuth 2.1 with appropriate security measures for both confidential and public clients.” | לא מגן על שרת stdio. הרשאה היא OPTIONAL ב-MCP בכללותו, והמפרט עצמו כותב: “Implementations using an STDIO transport SHOULD NOT follow this specification, and instead retrieve credentials from the environment.” שרת שרץ מקומית מוגן על ידי מי שמריץ אותו ועל ידי ההרשאות של המשתמש במכונה — לא על ידי OAuth. |
|---|
| PKCE, S256, וסירוב להמשיךbasic/authorization | “MCP clients MUST implement PKCE according to OAuth 2.1 Section 7.5.2 and MUST verify PKCE support before proceeding with authorization.”“MCP clients MUST use the S256 code challenge method when technically capable, as required by OAuth 2.1 Section 4.1.1.”“If code_challenge_methods_supported is absent, the authorization server does not support PKCE and MCP clients MUST refuse to proceed.” | החובה לאמת תמיכה ולסרב להמשיך היא חדשה בגרסה 2025-11-25. גרסת 2025-06-18 דרשה PKCE אך לא נשאה את הניסוח הזה. זו בדיוק השאלה שכדאי לשאול ספק שמצהיר “תומכים ב-MCP auth”: לפי איזו גרסה, ומה קורה אצלכם כשהשדה חסר. |
|---|
| RFC 9728 — Protected Resource Metadatabasic/authorization | “MCP servers MUST implement OAuth 2.0 Protected Resource Metadata (RFC9728). MCP clients MUST use OAuth 2.0 Protected Resource Metadata for authorization server discovery.”“The Protected Resource Metadata document returned by the MCP server MUST include the authorization_servers field containing at least one authorization server.” | מטא-דאטה של גילוי ניתנת להשפעה על ידי תוקף. השדות שמגיעים ממנה מזינים בקשות יוצאות מהשער — ולכן היא נכנסת ישירות לשורת ה-SSRF שבתחתית הטבלה, ולא נחשבת קלט אמין. |
|---|
| RFC 8707 — Resource Indicatorsbasic/authorization | “MCP clients MUST implement Resource Indicators for OAuth 2.0 as defined in RFC 8707 to explicitly specify the target resource for which the token is being requested.”“The resource parameter: 1. MUST be included in both authorization requests and token requests.”“MCP clients MUST send this parameter regardless of whether authorization servers support it.” | שליחת הפרמטר אינה קושרת את הטוקן. אם שרת ההרשאות לא מכבד אותו, הטוקן שיוחזר עדיין יהיה רחב מדי. נקודת האכיפה האמיתית היא בדיקת ה-audience בשורה הבאה, בצד שלנו. |
|---|
| בדיקת audience בכל טוקן נכנסbasic/authorization | “MCP servers MUST validate that access tokens were issued specifically for them as the intended audience, according to RFC 8707 Section 2.”“MCP servers MUST only accept tokens that are valid for use with their own resources.”“MCP servers MUST NOT accept or transit any other tokens.” | הציטוט הוא מגרסת 2025-11-25. בגרסת 2025-06-18 המשפט האמצעי נוסח “Authorization servers MUST only accept…” — כלומר הטיל את החובה על גורם אחר. אם אתם קוראים מסמך ישן, אתם קוראים חובה שאינה שלכם. |
|---|
| אף פעם לא מעבירים טוקן הלאהbasic/authorizationbasic/security_best_practices | “The MCP server MUST NOT pass through the token it received from the MCP client.”“MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server.” | המפרט מונה את התוצאות המתועדות של הפרת הכלל: עקיפה של “rate limiting, request validation, or traffic monitoring”, שבירת שרשרת הביקורת, ו“a malicious actor in possession of a stolen token can use the server as a proxy for data exfiltration”. הכלל אינו מגן מפני טוקן שהונפק כדין ומשמש לרעה — לשם כך צריך את האישור האנושי ואת לוג הביקורת. |
|---|
| גילוי שרת הרשאותbasic/authorization | “MCP authorization servers MUST provide at least one of the following discovery mechanisms: OAuth 2.0 Authorization Server Metadata (RFC8414) [—] OpenID Connect Discovery 1.0”“MCP clients MUST support both discovery mechanisms to obtain the information required to interact with the authorization server.” | שינוי אמיתי בין גרסאות: 2025-06-18 דרשה RFC 8414 בלבד ולא נתנה חלופת OIDC. לקוח שנבנה מול המסמך הישן עשוי שלא לדעת לקרוא מטא-דאטה של OIDC Discovery בכלל. |
|---|
| טיפול בסשניםbasic/security_best_practices | “MCP servers that implement authorization MUST verify all inbound requests. MCP Servers MUST NOT use sessions for authentication.”“MCP servers MUST use secure, non-deterministic session IDs. Generated session IDs (e.g., UUIDs) SHOULD use secure random number generators.” | מזהה לא-דטרמיניסטי הוא MUST, אבל ייצור שלו ממקור אקראי מאובטח הוא SHOULD בלבד — כלומר מימוש יכול לעמוד באות החוק ועדיין לייצר מזהים חלשים. המפרט ממליץ לקשור את המזהה לזהות המשתמש בצורה <user_id>:<session_id>. בנוסף, המנגנון כולו מוסר מהתעבורה ב-Streamable HTTP בגרסה 2026-07-28, כך שארכיטקטורה שנשענת עליו נבנית על משהו שכבר סומן ליציאה. |
|---|
| צמצום הרשאותbasic/security_best_practices | “Minimal initial scope set (e.g., mcp:tools-basic) containing only low-risk discovery/read operations”“Publishing all possible scopes in scopes_supported”“Using wildcard or omnibus scopes (*, all, full-access)” | צמצום הרשאות אינו מגן על שדה שכן נכלל בהרשאה. הסלמה בזמן ריצה נעשית באתגר: השרת מחזיר 403 עם error=“insufficient_scope”, ה-scope הנדרש ו-resource_metadata, ובתשובת 401 כולל את scope לפי RFC 6750 §3. אם הלקוח שלכם לא יודע לטפל באתגר, ההסלמה נכשלת בשקט. |
|---|
| ולידציה של כתובת ההרשאהbasic/security_best_practices | “MUST reject javascript:, data:, file:, vbscript:, and other potentially dangerous schemes”“The http:// scheme is acceptable only for loopback addresses (such as localhost, 127.0.0.1, or ::1) during local development; authorization servers in production MUST use https://.”“MCP clients MUST avoid shell execution when opening URLs: MUST NOT use shell commands (e.g., cmd.exe, sh, PowerShell) to open URLs” | הכללים האלה חלים על הלקוח, לא על השער שלנו — כלומר הם אינם בשליטתנו. אנחנו לא יכולים לתקן לקוח AI שפותח כתובת דרך פקודת מעטפת. המפרט מתעד את שתי התוצאות של דילוג על הבדיקות: הזרקת JavaScript שמקבלת הקשר XSS בתוך הלקוח, והזרקת פקודה שנותנת הרצת קוד בהרשאות המשתמש. מה שכן בשליטתנו: השער שלנו לעולם אינו מחזיר ללקוח כתובת הרשאה שהגיעה משרת צד שלישי בלי ולידציה של הסכימה. |
|---|
| הגנת SSRF בשערbasic/security_best_practices | “During OAuth metadata discovery, MCP clients fetch URLs from several sources that could be controlled by a malicious MCP server.”“MCP clients deployed to a server MUST consider SSRF risks and implement appropriate mitigations when fetching OAuth-related URLs.”“For server-side MCP client deployments, operators SHOULD consider using an egress proxy that enforces network policies.” | ההנחיות לחסימת טווחים פרטיים (10/8, 172.16/12, 192.168/16), loopback (127/8, ::1), link-local 169.254/16 ו-IPv6 פרטי (fc00::/7, fe80::/10) הן SHOULD ולא MUST — ולכן הן אינן מובטחות באף מימוש שלא בדקתם. המפרט מצביע במפורש על שירות המטא-דאטה של הענן בכתובת 169.254.169.254, על DNS rebinding ועל שרשראות הפניה, ומפנה ל-Smokescreen כפרוקסי יציאה. |
|---|
