Skip to main content
New in version 3.0.0 Authorization controls what authenticated users can do with your FastMCP server. While authentication verifies identity (who you are), authorization determines access (what you can do). FastMCP provides a callable-based authorization system that works at both the component level and globally via middleware. The authorization model centers on a simple concept: callable functions that receive context about the current request and return True to allow access or False to deny it. Multiple checks combine with AND logic, meaning all checks must pass for access to be granted.
Authorization relies on OAuth tokens which are only available with HTTP transports (SSE, Streamable HTTP). In STDIO mode, there’s no OAuth mechanism, so get_access_token() returns None and all auth checks are skipped.
When an AuthProvider is configured, all requests to the MCP endpoint must carry a valid token—unauthenticated requests are rejected at the transport level before any auth checks run. Authorization checks therefore differentiate between authenticated users based on their scopes and claims, not between authenticated and unauthenticated users.

Auth Checks

An auth check is any callable that accepts an AuthContext and returns a boolean. Auth checks can be synchronous or asynchronous, so checks that need to perform async operations (like reading server state or calling external services) work naturally.
FastMCP provides two built-in auth checks that cover common authorization patterns.

require_scopes

Scope-based authorization checks that the token contains all specified OAuth scopes. When multiple scopes are provided, all must be present (AND logic).

restrict_tag

Tag-based restrictions apply scope requirements conditionally. If a component has the specified tag, the token must have the required scopes. Components without the tag are unaffected.

Combining Checks

Multiple auth checks can be combined by passing a list. All checks must pass for authorization to succeed (AND logic).

Custom Auth Checks

Any callable that accepts AuthContext and returns bool can serve as an auth check. This enables authorization logic based on token claims, component metadata, or external systems.

Async Auth Checks

Auth checks can be async functions, which is useful when the authorization decision depends on asynchronous operations like reading server state or querying external services.
Sync and async checks can be freely combined in a list — each check is handled according to its type.

Error Handling

Auth checks can raise exceptions for explicit denial with custom messages:
  • AuthorizationError: Propagates with its custom message, useful for explaining why access was denied
  • Other exceptions: Masked for security (logged internally, treated as denial)

Component-Level Authorization

The auth parameter on decorators controls visibility and access for individual components. When auth checks fail for the current request, the component is hidden from list responses and direct access returns not-found.
Component-level auth controls both visibility (list filtering) and access (direct lookups return not-found for unauthorized requests). Additionally use AuthMiddleware to apply server-wide authorization rules and get explicit AuthorizationError responses on unauthorized execution attempts.

Server-Level Authorization

For server-wide authorization enforcement, use AuthMiddleware. This middleware applies auth checks globally to all components—filtering list responses and blocking unauthorized execution with explicit AuthorizationError responses.

Component Auth + Middleware

Component-level auth and AuthMiddleware work together as complementary layers. The middleware applies server-wide rules to all components, while component-level auth adds per-component requirements. Both layers are checked—all checks must pass.

Tag-Based Global Authorization

A common pattern uses restrict_tag with AuthMiddleware to apply scope requirements based on component tags.

Accessing Tokens in Tools

Tools can access the current authentication token using get_access_token() from fastmcp.server.dependencies. This enables tools to make decisions based on user identity or permissions beyond simple authorization checks.

Reference

AccessToken

The AccessToken object contains information extracted from the OAuth token.

AuthContext

The AuthContext dataclass is passed to all auth check functions. Access to the component object enables authorization decisions based on metadata like tags, name, or custom properties.

Imports