|
| 1 | +# Authentication examples |
| 2 | + |
| 3 | +MCP supports OAuth 2.1 authentication for protecting server resources. This section demonstrates both server-side token verification and client-side authentication flows. |
| 4 | + |
| 5 | +## OAuth server implementation |
| 6 | + |
| 7 | +FastMCP server with OAuth token verification: |
| 8 | + |
| 9 | +```python |
| 10 | +--8<-- "examples/snippets/servers/oauth_server.py" |
| 11 | +``` |
| 12 | + |
| 13 | +This example shows: |
| 14 | + |
| 15 | +- Implementing the `TokenVerifier` protocol for token validation |
| 16 | +- Using `AuthSettings` for RFC 9728 Protected Resource Metadata |
| 17 | +- Resource server configuration with authorization server discovery |
| 18 | +- Protected tools that require authentication |
| 19 | + |
| 20 | +## Complete authentication server |
| 21 | + |
| 22 | +Full Authorization Server implementation with token introspection: |
| 23 | + |
| 24 | +```python |
| 25 | +--8<-- "examples/servers/simple-auth/mcp_simple_auth/auth_server.py" |
| 26 | +``` |
| 27 | + |
| 28 | +This comprehensive example includes: |
| 29 | + |
| 30 | +- OAuth 2.1 authorization flows (authorization code, refresh token) |
| 31 | +- Token introspection endpoint for resource servers |
| 32 | +- Client registration and metadata management |
| 33 | +- RFC 9728 protected resource metadata endpoint |
| 34 | + |
| 35 | +## Resource server with introspection |
| 36 | + |
| 37 | +MCP Resource Server that validates tokens via Authorization Server introspection: |
| 38 | + |
| 39 | +```python |
| 40 | +--8<-- "examples/servers/simple-auth/mcp_simple_auth/server.py" |
| 41 | +``` |
| 42 | + |
| 43 | +This demonstrates: |
| 44 | + |
| 45 | +- Token introspection for validation instead of local token verification |
| 46 | +- Separation of Authorization Server (AS) and Resource Server (RS) |
| 47 | +- Protected MCP tools and resources |
| 48 | +- Production-ready server patterns |
| 49 | + |
| 50 | +## Token verification implementation |
| 51 | + |
| 52 | +Custom token verification logic: |
| 53 | + |
| 54 | +```python |
| 55 | +--8<-- "examples/servers/simple-auth/mcp_simple_auth/token_verifier.py" |
| 56 | +``` |
| 57 | + |
| 58 | +This component handles: |
| 59 | + |
| 60 | +- HTTP token introspection requests |
| 61 | +- Token validation with scope checking |
| 62 | +- RFC 8707 resource parameter validation |
| 63 | +- Error handling and logging |
| 64 | + |
| 65 | +## Simple authentication provider |
| 66 | + |
| 67 | +Authentication provider for development and testing: |
| 68 | + |
| 69 | +```python |
| 70 | +--8<-- "examples/servers/simple-auth/mcp_simple_auth/simple_auth_provider.py" |
| 71 | +``` |
| 72 | + |
| 73 | +This utility provides: |
| 74 | + |
| 75 | +- Simplified token generation for testing |
| 76 | +- Development authentication flows |
| 77 | +- Testing utilities for protected resources |
| 78 | + |
| 79 | +## Legacy Authorization Server |
| 80 | + |
| 81 | +Backward compatibility with older OAuth implementations: |
| 82 | + |
| 83 | +```python |
| 84 | +--8<-- "examples/servers/simple-auth/mcp_simple_auth/legacy_as_server.py" |
| 85 | +``` |
| 86 | + |
| 87 | +This example shows: |
| 88 | + |
| 89 | +- Support for non-RFC 9728 compliant clients |
| 90 | +- Legacy endpoint compatibility |
| 91 | +- Migration patterns for existing systems |
| 92 | + |
| 93 | +## OAuth architecture |
| 94 | + |
| 95 | +The MCP OAuth implementation follows the OAuth 2.1 authorization code flow with token introspection: |
| 96 | + |
| 97 | +```mermaid |
| 98 | +sequenceDiagram |
| 99 | + participant C as Client |
| 100 | + participant AS as Authorization Server |
| 101 | + participant RS as Resource Server<br/>(MCP Server) |
| 102 | + participant U as User |
| 103 | +
|
| 104 | + Note over C,RS: 1. Discovery Phase (RFC 9728) |
| 105 | + C->>RS: GET /.well-known/oauth-protected-resource |
| 106 | + RS->>C: Protected Resource Metadata<br/>(issuer, scopes, etc.) |
| 107 | + |
| 108 | + Note over C,AS: 2. Authorization Phase |
| 109 | + C->>AS: GET /authorize?response_type=code&client_id=... |
| 110 | + AS->>U: Redirect to login/consent |
| 111 | + U->>AS: User authenticates and consents |
| 112 | + AS->>C: Authorization code (via redirect) |
| 113 | + |
| 114 | + Note over C,AS: 3. Token Exchange |
| 115 | + C->>AS: POST /token<br/>(authorization_code grant) |
| 116 | + AS->>C: Access token + refresh token |
| 117 | + |
| 118 | + Note over C,RS: 4. Resource Access |
| 119 | + C->>RS: MCP request + Authorization: Bearer <token> |
| 120 | + RS->>AS: POST /introspect<br/>(validate token) |
| 121 | + AS->>RS: Token info (active, scopes, user) |
| 122 | + RS->>C: MCP response (if authorized) |
| 123 | + |
| 124 | + Note over C,AS: 5. Token Refresh (when needed) |
| 125 | + C->>AS: POST /token<br/>(refresh_token grant) |
| 126 | + AS->>C: New access token |
| 127 | +``` |
| 128 | + |
| 129 | +**Components:** |
| 130 | + |
| 131 | +- **Authorization Server (AS)**: Handles OAuth flows, issues and validates tokens |
| 132 | +- **Resource Server (RS)**: Your MCP server that validates tokens and serves protected resources |
| 133 | +- **Client**: Discovers AS through RFC 9728, obtains tokens, and uses them with MCP server |
| 134 | +- **User**: Resource owner who authorizes access |
| 135 | + |
| 136 | +## Security considerations |
| 137 | + |
| 138 | +When implementing authentication: |
| 139 | + |
| 140 | +1. **Use HTTPS**: All OAuth flows must use HTTPS in production |
| 141 | +2. **Token validation**: Always validate tokens on the resource server side |
| 142 | +3. **Scope checking**: Verify that tokens have required scopes |
| 143 | +4. **Introspection**: Use token introspection for distributed validation |
| 144 | +5. **RFC compliance**: Follow RFC 9728 for proper AS discovery |
| 145 | + |
| 146 | +These examples provide a complete OAuth 2.1 implementation suitable for production use with proper security practices. |
0 commit comments