Skip to main content
OAuth2 scopes allow you to implement fine-grained permissions in your API. Different endpoints can require different scopes, and tokens can have specific sets of permissions.

What Are OAuth2 Scopes?

Scopes are permissions that define what a token is allowed to do. For example:
  • me:read - Read user profile information
  • me:write - Update user profile
  • items:read - Read items
  • items:write - Create or update items
The format like items:read is a common convention, but OAuth2 treats scopes as opaque strings. You can use any naming scheme: read_items, items.read, etc.

Defining Scopes

First, define your scopes when creating the OAuth2 scheme:
These scopes will appear in the OpenAPI documentation at /docs, allowing users to see what permissions they can request.

SecurityScopes

FastAPI provides a special SecurityScopes class to access required scopes in your dependencies:
SecurityScopes is automatically populated by FastAPI based on all the scopes required by the dependency chain. It’s a special parameter like Request or Response.

Token with Scopes

Update your token model to include scopes:

Creating Tokens with Scopes

Modify create_access_token to include scopes:
In your login endpoint, include the requested scopes:

Validating Scopes

Update get_current_user to validate scopes:
1

Build authentication header

Include required scopes in the WWW-Authenticate header
2

Decode token

Extract username and scopes from the JWT
3

Get user

Retrieve user from database
4

Check scopes

Verify the token has all required scopes for this operation

Using Security() with Scopes

Now you can require specific scopes in your endpoints using Security() instead of Depends():
Security() is just like Depends(), but it allows you to specify required scopes. When you use Security() with scopes, FastAPI automatically passes them to your dependency through SecurityScopes.

Scope Hierarchy

You can also have dependencies that require different scopes:
In this case, read_own_items requires both me and items scopes because:
  1. read_own_items requires items scope
  2. get_current_active_user requires me scope
  3. FastAPI combines all required scopes: ["me", "items"]

Complete Example with Scopes

Testing with Scopes

1

Login with specific scopes

In the /docs interface, click “Authorize” and you’ll see checkboxes for each scope. Select the scopes you want.Or with cURL:
2

Test with full permissions

With both me and items scopes, you can access all endpoints:
3

Test with limited permissions

Get a token with only me scope:
Now you can access /users/me/ but not /users/me/items/:

OAuth2 Scopes in OpenAPI

When you define scopes, they automatically appear in your OpenAPI documentation:
  • The “Authorize” dialog shows checkboxes for each scope
  • Each endpoint shows which scopes it requires
  • The OpenAPI JSON includes the security requirements
This makes your API documentation interactive and helps developers understand what permissions they need for each operation.

Advanced Scope Patterns

Resource-Specific Scopes

Role-Based Scopes

Combining Scopes

You can require multiple scopes for a single endpoint:

Best Practices

Principle of Least Privilege

Request only the scopes you need. Don’t request all scopes by default.

Clear Scope Names

Use descriptive scope names that clearly indicate what permissions they grant.

Document Scopes

Provide clear descriptions for each scope in your OAuth2 scheme.

Validate on Server

Always validate scopes on the server. Never trust client-side validation.

Summary

You now have a complete, production-ready authentication system with: ✅ OAuth2 password flow ✅ JWT tokens with expiration ✅ Secure password hashing with Argon2 ✅ Fine-grained permissions with scopes ✅ Automatic OpenAPI documentation ✅ Type-safe dependencies
Remember: This is a strong foundation, but security is complex. For production systems:
  • Store secrets in environment variables
  • Use HTTPS only
  • Implement rate limiting
  • Add logging and monitoring
  • Consider refresh tokens for longer sessions
  • Have a security expert review your implementation

Further Reading

HTTP Basic Auth

Learn about simpler HTTP Basic authentication

API Keys

Alternative authentication with API keys