MCP 企业授权体系 2026 深度拆解：从零散 Token 到零接触 SSO，一次把 ID-JAG 讲透

一、引言：当 MCP 遇见企业级安全挑战

2024 年底，Anthropic 开源了 Model Context Protocol（MCP），这个旨在打通 AI 应用与外部数据源/工具的标准协议，在不到两年时间里迅速成为 AI Agent 开发的事实标准。GitHub Topics 页面上那句"an open standard that defines how AI applications connect to external tools, data sources, and services"，几乎概括了它的全部野心。

然而，当 MCP 从个人开发者的实验场走向企业生产环境时，一个尖锐的问题浮出水面：安全与授权。

早期 MCP 的授权模型相当原始——每个 MCP Server 各自为政，用户在首次连接时弹出一个授权对话框，提示"是否允许此工具访问你的文件/数据库/API"。这种模式在个人使用场景下勉强可用，但在企业环境中几乎是一场噩梦：

• 没有集中管控：员工 A 的授权和员工 B 完全隔离，IT 无法审计谁访问了什么工具
• 没有 SSO：每个 MCP Server 都要单独登录，几十个 Server 就意味着几十次登录
• 没有权限策略：管理员无法定义"只有数据工程团队才能访问数据库类 MCP Server"
• 无法统一撤销：员工离职时，管理员无法一次性撤销其所有 MCP 访问权限

2026 年 7 月 12 日，MCP 团队正式将**企业托管授权扩展（Enterprise Managed Authorization）**提升至稳定状态，Anthropic 和微软率先在其客户端（Claude、Claude Code、Claude Cowork、VS Code）中提供支持，Okta 成为首家支持该功能的身份提供商（IdP）。

这一里程碑意味着：MCP 正式从"能用"进入"企业安全可用"的新阶段。

本文将从问题本质出发，深度拆解 MCP 企业授权的技术架构、ID-JAG（Identity Assertion JWT Authorization Grant）核心原理、Okta 集成的具体实现，以及企业落地的实战指南。

二、当前 MCP 授权模型的问题分析

2.1 现状：每个 Server 一把锁

在稳定版发布之前，MCP 的授权机制大致如下：

用户启动 AI 应用（Claude Desktop / Cursor / Copilot）
       ↓
AI 调用某个 MCP Server 的工具（如 filesystem.read）
       ↓
MCP Client 检测到这是首次连接，弹出授权对话框
"Allow access to ~/Documents? [Allow / Deny]"
       ↓
用户点击 Allow → 授权结果存储在本地配置文件（如 claude_desktop_config.json）

这个流程有几个根本性问题：

1. 授权粒度极粗

当前模型授权的是"整个 Server"，而非"具体工具"。一旦你允许了一个 MCP Server 访问文件系统，它理论上可以读取你 home 目录下的所有文件。这在企业场景下是无法接受的——DLP（数据泄露防护）部门会直接否决这种方案。

2. 无法区分用户身份

当同一个 MCP Server 被多个用户使用时，Server 端无法知道调用者是谁。这意味着你无法基于用户角色动态授予或限制权限。

3. 令牌生命周期不透明

本地存储的授权令牌没有标准的过期机制，也没有统一的刷新策略。有些 Server 永不过期，有些则在服务端随意失效，体验碎片化严重。

4. 无审计能力

IT 安全团队无法知道"张三在什么时间通过哪个 MCP Server 访问了哪些数据"。一旦发生数据泄露，连溯源都做不到。

2.2 企业需求：五个关键能力

企业级 MCP 授权体系必须解决以下问题：

三、ID-JAG：MCP 企业授权的核心协议

3.1 什么是 ID-JAG

ID-JAG（Identity Assertion JWT Authorization Grant） 是一种新兴的 OAuth 2.0 扩展规范（目前已是 IETF 草案阶段），由 MCP 团队与 Okta 联合提出。其核心思想是：用企业身份提供商的断言（Identity Assertion）直接换取 MCP Server 的访问令牌，绕过传统的用户名/密码交互式认证。

在传统 OAuth 2.0 流程中，客户端需要与授权服务器完成一个交互式的授权码流程（Authorization Code Flow）：

用户 → 授权页面 → 登录 → 同意授权 → 授权码 → 令牌

这套流程对于 Web 应用很友好，但对于命令行工具、CI/CD 环境、AI Agent 来说简直是噩梦——没有浏览器、没有用户交互、没有回调 URL。

ID-JAG 的创新之处在于：它允许企业身份提供商直接签发一个经过验证的 JWT 断言（Identity Assertion），MCP Server 的授权服务器将其兑换为访问令牌：

企业 IdP（Okta/Azure AD）
    ↓ 签发 Identity Assertion JWT
MCP Client
    ↓ 发送 ID-JAG 请求（含 JWT 断言）
MCP Server 授权服务器
    ↓ 验证 JWT，颁发访问令牌
MCP Client
    ↓ 使用访问令牌
MCP Server 资源

3.2 ID-JAG 的技术细节

JWT 断言的构造

来自 IdP 的 Identity Assertion JWT 通常包含以下标准声明：

{
  "iss": "https://your-company.okta.com",
  "sub": "alice@company.com",
  "aud": "mcp-server-fs",
  "iat": 1752350400,
  "exp": 1752354000,
  "jti": "unique-assertion-id-12345",
  "groups": ["engineering", "data-team"],
  "roles": ["read-only"]
}

其中：

• iss：签发机构（Okta/Azure AD/Google Workspace）
• sub：用户主体标识（邮箱或员工 ID）
• aud：目标 MCP Server 的标识符
• groups：用户在 IdP 中所属的安全组
• roles：IdP 中定义的 MCP 特定角色

令牌兑换流程

MCP Server 授权服务器收到 ID-JAG 请求后，执行以下验证步骤：

# 伪代码：MCP Server 授权服务器的令牌兑换逻辑
import jwt
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import ec

async def exchange_id_jag_for_token(id_jag_request: IDJAGRequest) -> TokenResponse:
    # Step 1: 提取 JWT 断言
    assertion = id_jag_request.assertion  # JWT 字符串
    
    # Step 2: 获取 IdP 的公钥（通过 JWKS 端点）
    jwks = await fetch_jwks(id_jag_request.issuer)  # e.g. https://company.okta.com/.well-known/jwks.json
    public_key = jwks.get_key(assertion.header.kid)
    
    # Step 3: 验证 JWT 签名
    claims = jwt.decode(
        assertion,
        public_key,
        algorithms=["ES256"],  # ECDSA for performance
        audience=id_jag_request.server_id,
        issuer=id_jag_request.issuer
    )
    
    # Step 4: 检查时间有效性
    now = time.time()
    assert claims["iat"] <= now < claims["exp"], "Assertion expired or not yet valid"
    
    # Step 5: 业务策略检查（基于 groups 和 roles）
    allowed_tools = resolve_permissions(claims["groups"], claims["roles"], server_id)
    
    # Step 6: 颁发 MCP 访问令牌（限定工具范围）
    access_token = create_mcp_token(
        subject=claims["sub"],
        tools=allowed_tools,          # 细粒度工具级权限
        expires_in=3600,             # 1小时过期
        issued_by=claims["iss"]
    )
    
    return TokenResponse(access_token=access_token, tools=allowed_tools)

细粒度工具级权限

这是 ID-JAG 最令人兴奋的特性之一。传统方案授权的是整个 MCP Server，而 ID-JAG 可以做到基于 JWT 声明动态决定用户可用的工具子集：

def resolve_permissions(groups: list[str], roles: list[str], server_id: str) -> list[str]:
    """
    基于用户在 IdP 中的组和角色，解析可用的 MCP 工具
    """
    # 从配置文件中加载权限矩阵
    permission_matrix = {
        "engineering": {
            "filesystem": ["read", "list", "stat"],
            "database": ["query:read-only"],
            "api": ["get", "list"]
        },
        "data-team": {
            "filesystem": ["read", "write", "list"],
            "database": ["query:read-only", "query:write"],
            "api": ["get", "post", "list"]
        }
    }
    
    # 取用户所在所有组的权限并集
    allowed_tools = set()
    for group in groups:
        if group in permission_matrix:
            allowed_tools.update(permission_matrix[group].get(server_id, []))
    
    return list(allowed_tools)

最终颁发的 MCP 访问令牌中，明确限定了用户可以调用的工具：

{
  "access_token": "eyJhbGciOiJFUzI1NiJ9...",
  "token_type": "bearer",
  "expires_in": 3600,
  "scope": "filesystem:read filesystem:list database:query:read-only"
}

3.3 架构设计哲学：策略与流量分离

MCP 团队在发布声明中特别强调了这一点：企业托管层决定用户是否可以将客户端连接到 Server，以及对应的权限范围，但在令牌颁发后不会检查 MCP 流量。

这个设计哲学有深意：

┌─────────────────────────────────────────────────────┐
│           Enterprise Managed Authorization          │
│                                                     │
│   身份层：IdP 验证用户身份，签发 JWT 断言            │
│   策略层：管理员定义谁能访问哪个 Server/工具         │
│   令牌层：MCP Server 授权服务器颁发受限令牌           │
└─────────────────────────────────────────────────────┘
                        ↓
┌─────────────────────────────────────────────────────┐
│               MCP Server（业务逻辑）                │
│                                                     │
│   MCP Client 携带访问令牌调用工具                    │
│   Server 仅验证令牌有效性，不再重复检查身份           │
│   业务逻辑与安全策略彻底解耦                        │
└─────────────────────────────────────────────────────┘

这样做的好处是：

• 性能无损：MCP 运行时不需要每次工具调用都去 IdP 做远程验证
• 架构清晰：安全策略集中管理，业务 Server 专注业务逻辑
• 可扩展：可以灵活切换 IdP 或策略引擎，不影响业务层

四、企业落地实战：从 Okta 到 MCP Server

4.1 整体部署架构

┌─────────────────────────────────────────────────────────────┐
│                     企业内网 / 云端                         │
│                                                             │
│   ┌──────────────┐      ┌──────────────┐                    │
│   │  Okta IdP    │      │  MCP Server  │                    │
│   │  (身份断言)   │ ───→ │  授权服务器   │                    │
│   └──────────────┘      └──────┬───────┘                    │
│                                │                            │
│                    ┌────────────┴───────────┐               │
│                    │  MCP Server 资源服务    │               │
│                    │  (filesystem/db/api)  │               │
│                    └───────────────────────┘               │
│                                                             │
│   Claude Desktop ──→ MCP Client ──→ 授权流程 ──→ 工具调用   │
└─────────────────────────────────────────────────────────────┘

4.2 Okta 配置步骤

第一步：创建 MCP 应用集成

在 Okta 管理后台，创建一个新的应用集成：

# Okta 应用配置（YAML 格式）
# 设置 → 应用 → 创建应用集成 → OIDC - OpenID Connect
name: MCP Enterprise Integration
sign-in method: SPA
grant type: Authorization Code + PKCE

# 回调 URL（Claude Desktop 的 MCP 客户端重定向地址）
redirect_uri: http://localhost:8080/callback

# 分配的组（哪些团队可以使用此 MCP 集成）
group assignments:
  - engineering
  - data-platform
  - devops

第二步：配置 JWT 断言策略

Okta 需要配置当 MCP Client 请求时，签发的 JWT 包含正确的声明：

// Okta Access Policy - 附加 MCP 所需的声明
{
  "conditions": {
    "grantType": {
      "include": ["authorization_code"]
    },
    "scopes": {
      "include": ["openid", "profile", "email", "mcp:server:access"]
    }
  },
  "actions": {
    "token": {
      "inlineHook": null,
      "refreshTokenLifetime": 86400,
      "accessTokenLifetime": 3600,
      "idTokenLifetime": 3600,
      // 关键：在 JWT 中嵌入 MCP 所需的组信息
      "customClaims": {
        "mcp:server_access": {
          "filesystem": ["read", "list"],
          "database": ["query:read-only"],
          "api": ["get"]
        }
      }
    }
  }
}

第三步：获取 Okta 的 JWKS 端点

MCP Server 授权服务器需要 Okta 的公钥来验证 JWT 签名：

# Okta JWKS 端点格式
# https://{your-domain}.okta.com/oauth2/v1/keys

curl https://company.okta.com/oauth2/v1/keys \
  -H "Accept: application/json"

响应示例：

{
  "keys": [
    {
      "kty": "EC",
      "kid": "key-id-abc123",
      "use": "sig",
      "alg": "ES256",
      "crv": "P-256",
      "x": "f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
      "y": "x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0"
    }
  ]
}

4.3 MCP Server 端配置

现在看 MCP Server 这边如何集成 ID-JAG：

# mcp_server_auth/server.py
import os
from mcp_server_auth import MCPAuthorizationServer
from mcp_server_auth.providers.okta import OktaJWKSAuthProvider

# 初始化授权服务器
auth_server = MCPAuthorizationServer(
    server_id="enterprise-filesystem",
    server_name="企业文件系统 MCP Server",
    
    # Okta 作为身份提供商的验证器
    auth_provider=OktaJWKSAuthProvider(
        issuer=os.environ["OKTA_ISSUER"],        # https://company.okta.com/oauth2/default
        jwks_uri=os.environ["OKTA_JWKS_URI"],    # https://company.okta.com/oauth2/v1/keys
        audience="mcp-server-fs"                 # 预期的 JWT audience
    ),
    
    # 权限解析策略
    permission_resolver=RoleBasedPermissionResolver(
        # 配置 IdP 组到 MCP 工具的映射
        group_permissions={
            "engineering": {
                "filesystem:read": True,
                "filesystem:list": True,
                "filesystem:stat": True,
                "filesystem:write": False,   # 工程团队只能读，不能写
            },
            "data-platform": {
                "filesystem:read": True,
                "filesystem:list": True,
                "filesystem:write": True,
                "database:query:*": True,     # 数据平台团队可以操作数据库
            }
        }
    )
)

# 启动授权服务器（与 MCP Server 并行运行）
auth_server.start(port=8090)

4.4 AI 客户端侧配置

在 Claude Desktop 或其他支持 MCP 的客户端中，配置 Server 时只需指定 IdP：

// claude_desktop_config.json
{
  "mcpServers": {
    "enterprise-filesystem": {
      "command": "npx",
      "args": ["-y", "@company/mcp-filesystem-server"],
      "env": {
        "MCP_AUTH_MODE": "enterprise",
        "MCP_AUTH_ISSUER": "https://company.okta.com/oauth2/default",
        "MCP_AUTH_SERVER_URL": "https://mcp-auth.company.internal"
      }
    }
  }
}

用户首次连接时，Claude Desktop 会自动重定向到 Okta SSO 登录页面，完成后即自动获取授权——无需手动配置 API Key，无需复制 Token，零接触。

五、与现有方案的对比

5.1 vs 传统 API Key 方案

5.2 vs MCP 原有本地授权

5.3 vs 普通 OAuth 2.0

六、常见企业场景分析

场景一：数据库 MCP Server 的多租户权限

大型企业的数据团队有多个子团队，每个子团队只能访问自己的 Schema：

# 高级权限配置：基于数据库 Schema 的多租户隔离
permission_rules = [
    Rule(
        match_group="analytics-team",
        match_claims={"department": "analytics"},
        allowed_tools={
            "database:query": lambda params: (
                params["sql"].startswith("SELECT") and
                params["schema"] in ["analytics_public", "analytics_staging"] and
                not any(keyword in params["sql"].upper() 
                       for keyword in ["DROP", "DELETE", "TRUNCATE", "ALTER"])
            )
        }
    ),
    Rule(
        match_group="ml-engineering",
        match_claims={"department": "ml"},
        allowed_tools={
            "database:query": lambda params: (
                params["schema"] in ["ml_training", "ml_features"]
            )
        }
    )
]

场景二：Git MCP Server 的最小权限

代码仓库权限应该与 Git 权限一致：

# Git MCP Server 权限配置
permission_policy:
  # 只允许访问用户在 Okta 中有权限的仓库
  repository_filter: "user:accessible_repos"
  
  # 禁止 push 到主分支（只能通过 PR）
  push_restrictions:
    main: false          # 禁止直接推 main
    release/*: false     # 禁止推 release 分支
    feature/*: true      # 允许推 feature 分支
  
  # 审计：记录所有操作
  audit:
    enabled: true
    sink: "sentinel-audit-log"
    events: ["read", "clone", "push", "create_branch", "delete_branch"]

场景三：CI/CD 中的非交互式授权

在 GitHub Actions 或 GitLab CI 中，MCP Client 无法打开浏览器。ID-JAG 的设计同样支持这种场景：

# GitHub Actions workflow 中的 MCP 使用
jobs:
  code-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup MCP with ID-JAG Service Account
        env:
          # 服务身份：CI/CD 使用服务账号的断言
          OKTA_CLIENT_ID: ${{ secrets.OKTA_MCP_SERVICE_CLIENT_ID }}
          OKTA_PRIVATE_KEY: ${{ secrets.OKTA_MCP_SERVICE_PRIVATE_KEY }}
        run: |
          # 使用 Okta 的 JWT Bearer Flow 获取断言
          ASSERTION=$(okta-jwt-cli get-assertion \
            --client-id "$OKTA_CLIENT_ID" \
            --private-key "$OKTA_PRIVATE_KEY" \
            --issuer "https://company.okta.com/oauth2/default" \
            --scope "mcp:server:access")
          
          # 将断言注入 MCP Client 环境
          echo "MCP_ID_JAG_ASSERTION=$ASSERTION" >> $GITHUB_ENV
      
      - name: Run AI Code Review via MCP
        uses: company/ai-reviewer-mcp@v3
        with:
          auth_mode: id_jag
          assertion_env_var: MCP_ID_JAG_ASSERTION

七、安全最佳实践

7.1 JWT 断言的安全要点

断言有效期必须短：IdP 签发的 JWT 断言有效期建议不超过 5 分钟。MCP Client 应在断言过期前主动刷新：

class IDJAGTokenManager:
    def __init__(self, okta_config: OktaConfig):
        self.okta = okta_config
        self._assertion_cache: Optional[str] = None
        self._assertion_expires_at: float = 0
        self._token_cache: dict[str, str] = {}  # server_id → access_token
    
    async def get_access_token(self, server_id: str) -> str:
        # 如果缓存的令牌还有效，直接返回
        if server_id in self._token_cache:
            cached = self._token_cache[server_id]
            if time.time() < cached.expires_at - 60:  # 提前60秒刷新
                return cached.token
        
        # 检查断言是否过期，过期则重新获取
        if time.time() >= self._assertion_expires_at:
            self._assertion_cache = await self._refresh_assertion()
            self._assertion_expires_at = time.time() + 240  # 4分钟
        
        # 用断言兑换令牌
        token = await self._exchange_assertion_for_token(
            assertion=self._assertion_cache,
            server_id=server_id
        )
        
        self._token_cache[server_id] = TokenCache(
            token=token.access_token,
            expires_at=time.time() + token.expires_in
        )
        
        return token.access_token
    
    async def _refresh_assertion(self) -> str:
        # 使用 Okta JWT Bearer 流程获取新断言
        client_assertion = await self.okta.create_client_assertion()
        
        response = await self.okta.client.post(
            "/oauth2/v1/token",
            data={
                "grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer",
                "client_assertion": client_assertion,
                "client_assertion_type": "urn:ietf:params:oauth:client-assertion-type:jwt-bearer",
                "scope": "openid profile email mcp:server:access"
            }
        )
        
        return response.json()["id_token"]  # 作为断言使用

使用 ECDSA（ES256）而非 RSA：在移动设备和边缘计算场景下，ECDSA 签名验证比 RSA 快 10 倍以上，且密钥更小。Okta 和 Azure AD 均已支持 ES256。

7.2 MCP Server 端安全清单

# production-mcp-server-config.yaml
security:
  # 强制要求加密传输
  require_tls: true
  min_tls_version: "1.3"
  
  # JWT 断言验证
  assertion_validation:
    required_claims:
      - iss      # 必须包含签发者
      - sub      # 必须包含用户标识
      - aud      # 必须包含目标 Server ID
      - iat      # 必须包含签发时间
      - exp      # 必须包含过期时间
    max_assertion_age_seconds: 300  # 断言最大有效期5分钟
    allowed_issuers:
      - "https://company.okta.com/oauth2/default"
      - "https://login.microsoftonline.com/{tenant}/v2.0"
    key_rotation:
     jwks_cache_ttl_seconds: 3600   # JWKS 缓存1小时
      force_refresh_after_hours: 24 # 每24小时强制刷新
  
  # 速率限制（防止令牌泄露后的滥用）
  rate_limits:
    per_token:
      requests_per_minute: 120
      requests_per_hour: 5000
    per_ip:
      requests_per_minute: 60
  
  # 审计日志
  audit:
    enabled: true
    format: "json"
    destination: "sentinel:auditlog"
    pii_handling: "mask"  # 自动脱敏 PII

7.3 管理员视角的权限矩阵

八、性能与延迟分析

8.1 授权流程的开销

一个完整的 ID-JAG 授权流程（含 Okta JWT 签发）在网络良好的情况下：

首次连接需要 20-80ms，对于 AI 工具调用来说完全可接受。缓存命中后几乎零额外延迟。

8.2 与传统方案的性能对比

传统 API Key 方案：
  首次连接：0ms（无认证流程）
  缺点：无安全，无审计，无细粒度

OAuth 2.0 Authorization Code 方案（Browser-based）：
  首次连接：2000-5000ms（打开浏览器 + 登录 + 授权 + 回调）
  缺点：CLI 不可用，CI/CD 不可用

ID-JAG 方案：
  首次连接：20-80ms
  后续连接：0.5-2ms（令牌缓存）
  优点：全程无交互，支持所有环境

九、未来展望：MCP 安全的下一步

9.1 即将到来的增强

根据 MCP 团队的发展路线图，以下功能正在积极开发中：

1. 双向 TLS（mTLS）认证

未来的 MCP Server 将支持客户端证书认证，实现双向 TLS——不仅验证用户身份，还要验证 MCP Client 本身的真实性。这将彻底杜绝中间人攻击。

2. 跨 Server 委托授权

当一个 MCP Server 需要调用另一个 MCP Server 时，当前模型要求每个 Server 单独授权。未来将支持委托令牌（Delegation Token）：用户授权 Server A，Server A 在需要时自动代表用户访问 Server B，无需用户重复授权。

// 委托令牌的预期格式
{
  "delegation": {
    "from_user": "alice@company.com",
    "via_server": "orchestrator-server",
    "to_server": "filesystem-server",
    "max_depth": 3,         // 最多委托3层
    "remaining_depth": 2    // 当前剩余深度
  }
}

3. 实时权限变更（无需重新登录）

当前模型中，管理员修改权限后，用户需要重新获取令牌才能感知变化。未来将支持令牌撤销（Token Revocation）和推送刷新（Push-based Refresh），使权限变更实时生效。

4. 合规报告自动化

企业版 MCP 将提供标准化的合规报告导出功能，直接对接 SOC 2、ISO 27001 的审计要求，减少合规团队的手工工作。

9.2 ID-JAG 的标准化进程

ID-JAG 目前已是 IETF 草案阶段，正在积极推动成为正式 RFC。如果成功，它将成为 OAuth 2.0 的标准扩展，任何支持 OAuth 2.0 的 IdP（Okta、Azure AD、Google Workspace、Auth0、Ping Identity）都可以原生支持 MCP 的企业授权，而无需 MCP 团队维护特殊的适配器。

这意味着：MCP 企业授权的能力将指数级扩散——当 ID-JAG 成为标准后，全球数十亿企业用户将自动获得对 MCP 企业授权的支持。

十、总结：MCP 从"能用"到"企业安全可用"的跨越

MCP 企业授权稳定版的发布，是 AI Agent 生态走向成熟的标志性事件。在此之前，MCP 的安全问题一直是企业采用的最大障碍——CISO（首席信息安全官）们不可能批准一个连 SSO 都做不到的工具进入生产环境。

ID-JAG 协议的意义不仅在于解决了 MCP 的授权问题，更在于它示范了一种面向 AI 原生应用的新型安全架构：

• 身份即基础设施：企业的 IdP（Okta/Azure AD）成为 AI 工具访问的统一门卫
• 策略即代码：权限策略与 MCP Server 代码分离，管理员可通过声明式配置管理权限
• 最小权限原生支持：基于 IdP 组和角色的细粒度工具级控制
• 可审计的 AI 工具调用：所有访问行为可追溯，满足合规要求

对于开发者而言，这意味着：

1. 现在：如果你的企业使用 Okta，可以立即启用 MCP 企业授权功能，让团队成员享受 SSO + 细粒度权限的体验
2. 规划中：如果你在为 MCP Server 添加企业支持，开始接入 ID-JAG 规范，让你的 Server 天然具备企业安全能力
3. 长期：关注 ID-JAG 的 IETF 标准化进程，它可能成为 AI 时代 API 安全的新范式

MCP 的企业安全故事，才刚刚开始。

参考来源：

• MCP 官方企业授权发布公告（2026-07-12）
• MCP 企业授权层正式上线：Anthropic、微软等率先支持（2026-07-13）
• Model Context Protocol GitHub: https://github.com/modelcontextprotocol
• IETF ID-JAG Draft Specification
• Okta MCP Integration Documentation