Skip to main content
FastQL’s core has no built-in authentication machinery — authentication is a transport concern, and the core is deliberately framework-agnostic. The recommended pattern has three layers:
  1. Extract credentials in the transport layer (middleware, dependency injection).
  2. Pass the authenticated identity into resolvers via the Context object.
  3. Enforce access rules with permissions or field extensions.

Step 1 — Extract credentials in the transport layer

Authentication belongs in the framework integration, not in the GraphQL schema. Extract the token or session in HTTP middleware or a framework dependency, then make the resolved identity available when the context is constructed. FastAPI example:
ASGI middleware example (framework-agnostic):

Step 2 — Surface the identity through Context

Override get_context (or its framework-specific equivalent) to inject the resolved identity into the FastQL context:
The ASGI, Starlette, Flask, and Django adapters each have equivalent context injection hooks — see the integrations section for your framework.

Step 3 — Enforce access with permissions

Use BasePermission to define reusable access rules and apply them to fields:
When a permission check fails, FastQL returns a field error with the permission’s message and null for the field value (subject to the field’s nullability).

Field extensions for cross-cutting auth rules

For rules that apply to many fields, a field extension is cleaner than repeating permissions=[...] everywhere:
See Extensions and permissions for the full field extension API.

What not to do

Do not perform authentication inside field resolvers. Resolvers are called per-field and may run in parallel — putting auth logic there makes it easy to miss a field, hard to test, and expensive to audit.
  • Don’t verify tokens inside @Field resolvers.
  • Don’t put credentials in GraphQL arguments — they appear in logs and introspection.
  • Do use the transport layer for extraction and Permission / field extensions for enforcement.