Overview
FastApps provides three decorators for per-widget authentication control:@auth_required
- Require OAuth authentication@no_auth
- Explicitly public (opt-out)@optional_auth
- Support both authenticated and anonymous access
@auth_required
Require OAuth authentication for a specific widget.Basic Usage
With Scopes
Require specific OAuth scopes:Syntax Options
All these are valid:@no_auth
Mark a widget as explicitly public (opt-out of server authentication).Usage
When to Use
Use@no_auth
when:
- Widget displays public information
- Server has authentication enabled, but this widget should be public
- No user-specific data is needed
Important
Even with@no_auth
, you can still check if a user is authenticated:
@optional_auth
Support both authenticated and anonymous access.Basic Usage
Freemium Pattern
Perfect for freemium models:Authentication Inheritance
Per MCP spec: “Missing field: inherit server default policy” Widgets without explicit decorators inherit the server’s authentication policy:Server Auth | Widget Decorator | Result |
---|---|---|
Enabled | None | Required (inherits server) |
Enabled | @auth_required | Required (widget-specific scopes) |
Enabled | @no_auth | Public (opt-out) |
Enabled | @optional_auth | Optional |
Disabled | None | Public |
Disabled | @auth_required | Required |
Disabled | @no_auth | Public |
Disabled | @optional_auth | Optional |
Examples
Scenario 1: Server requires auth, widget inheritsScope Enforcement
Widget-Specific Scopes
Checking Scopes in Code
Best Practices
1. Use Specific Scopes
2. Check Authentication Status
3. Provide Helpful Error Messages
4. Use Type Hints
5. Explicit Opt-Out
Next Steps
- User Context - Access user information and claims
- Examples - Real-world authentication patterns
- Server Configuration - Configure server-level auth