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:
- Extract credentials in the transport layer (middleware, dependency injection).
- Pass the authenticated identity into resolvers via the
Context object.
- Enforce access rules with permissions or field extensions.
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.