litestar-auth-guards

Litestar Auth and Guards

Use this skill for authentication boundaries, authorization checks, guard composition, and user context.

Code Style Rules

• Put auth and permission checks in Guards or middleware, not handler bodies.
• Prefer Controller-level guards when a whole domain shares a policy.
• Raise Litestar HTTP exceptions or domain exceptions consistently.
• Keep tenant isolation explicit in guard logic and service filters.

Quick Reference

• Guard patterns: guards.md
• Middleware user loading: litestar-middleware
• Realtime auth: litestar-realtime

Workflow

1. Determine where identity is loaded.
2. Add Guards at app, Controller, or route scope.
3. Keep permission checks reusable and testable.
4. Verify denial paths and authenticated success paths.

Guardrails

• Do not inline auth checks in handlers.
• Do not make Guards perform database work repeatedly when middleware can load the user once.
• Do not trust client-supplied tenant IDs without server-side scoping.
• Do not use HTTP-only assumptions for WebSocket auth.

Validation Checkpoint

• Guard scope matches the policy scope.
• Denial paths return the expected status.
• Handlers contain no duplicated auth branching.
• WebSocket routes use an explicit browser-compatible auth path.

Example

from litestar.connection import ASGIConnection
from litestar.exceptions import PermissionDeniedException
from litestar.handlers import BaseRouteHandler

async def requires_active_user(connection: ASGIConnection, _: BaseRouteHandler) -> None:
    if not connection.user or not connection.user.is_active:
        raise PermissionDeniedException("Authentication required")

References Index

• guards.md

Official References

• https://docs.litestar.dev/ - Litestar documentation
• https://docs.litestar.dev/latest/reference/ - Litestar API reference

Shared Styleguide Baseline

• General
• Python
• Litestar