@authenticated
The @authenticated directive declares a GraphQL definition to require the agent (person, service, or device) to be authenticated. Lack of authentication will yield an authorization error.
Minimum requirements
Make sure you have correctly set up Authentication & Authorization.
Definition
Declaration
The @authenticated directive can be declared on enums, field definitions, interfaces, objects, and scalars. However, there are some differences between declaration on leaf definitions and parent definitions.
Declaration on leaf definitions (enums and scalars)
When @authenticated is declared on a leaf definition, @authenticated will be applied to all field definitions whose named type (the innermost response type name) is the respective leaf definition within that subgraph.
If the same leaf definition is defined in another subgraph without @authenticated, the corresponding field definitions unique to that that subgraph will be unaffected. But note that @authenticated could be applied to those field definitions through other means.
If at least one instance of a shared field is declared @authenticated, that field will be declared @authenticated in the federated graph (see Federation). Consider the following example:
In subgraph-a, above, @authenticated has been declared on two leaf definitions:
The enum "Enum"
The scalar "Scalar"
And those leaf definitions are returned at the following field paths:
Query.enumQuery (named type name is "Enum")
Query.scalarQuery (named type name is "Scalar")
Object.enumField (named type name is "Enum")
Object.scalarField (named type name is "Scalar")
Consequently, @authenticated would be applied to all field definitions at the paths listed above. The normalized graph would look like so:
Declaration on object definitions
When @authenticated is declared on an object definition, @authenticated will be applied to all field definitions defined on the object definition within that subgraph.
If the same object definition is defined in another subgraph without @authenticated, the corresponding field definitions unique to that subgraph be unaffected. But note that @authenticated could be applied to those field definitions through other means.
If at least one instance of a shared field is declared @authenticated, that field definition will be declared @authenticated in the federated graph (see Federation). Consider the following example:
In subgraph-b, above, @authenticated has been declared on two object definitions:
The root object "Query"
The object "Object"
And those object definitions define the following field definitions:
Query.objectQuery
Query.objectsQuery
Object.intField
Object.stringField
Consequently, @authenticated would be applied to all field definitions at the paths listed above. The normalized graph would look like so:
Declaration on interface definitions
When @authenticated is declared on an interface definition, @authenticated will be applied to all field definitions defined on the interface definition within that subgraph.
If the same interface definition is defined in another subgraph without @authenticated, the corresponding field definitions unique to that subgraph be unaffected. But note that @authenticated could be applied to those field definitions through other means.
In addition, @authenticated will be applied to the corresponding field definitions defined on the objects that implement that interface within that subgraph.
If at least one instance of a shared field is declared @authenticated, that field definition will be declared @authenticated in the federated graph (see Federation). Consider the following example:
In subgraph-c, above, @authenticated has been declared on the interface definition "Interface", which is implemented by two object definitions:
Object
AnotherObject
This interface defines the following field definitions:
Interface.intField
Interface.stringField
Consequently, @authenticated would be applied to all field definitions at the paths listed above, in addition to the same field definitions that are defined on the object definitions that implement that interface.
The normalized subgraph would look like so:
When @authenticated is declared on an interface field definition directly, the corresponding field definitions on the object types that implement that interface within that subgraph will also declare @authenticated. For example:
The subgraph above, subgraph-d, would normalize into the following subgraph:
Federation
The @authenticated directive will persist in the federated schema. Consequently, if @authenticated is declared on a field definition in one graph, and the same field definition (a shared field) is defined in another graph without @authenticated, then @authenticated will be declared on the federated field. This also means selecting this field will always require authentication, regardless of whether it would be resolved from a subgraph that did not declare @authenticated. Consider the following two subgraphs and the resulting federated graph. The federated graph includes descriptions explaining how each @authenticated directive has persisted.
Errors
In the event that an unauthenticated agent selects a non-nullable field that is declared @authenticated, an authorization error will be returned, and the entire data will be null (see Non-nullable authenticated data requested among unauthenticated data).
In the event that an unauthenticated agent selects a nullable field that is declared @authenticated, an authorization error will be returned, and the specific field will be null (see Partial data):
Partial data (nullable authenticated data)
Imagine an unauthenticated agent selects a field that is declared @authenticated and the response type of that field is nullable. However, the agent also queries a field that is not declared @authenticated (nor are any potential nested fields). In this event, an authorization error will still be returned, but the specific data that requires authentication will be null, while the data not requiring authentication will be returned. Consider the following federated graph and corresponding query:
An unauthenticated agent sending the query above would receive something like the following:
Non-nullable authenticated data requested among unauthenticated data
In the event an unauthenticated agent selects any non-nullable fields that require authentication, an authorization error will be returned, and the entire data will return null. This is true even if one or more field selections did not require authentication or are nullable. Consider the following federated graph and corresponding query:
An unauthenticated agent sending the query above would receive something like the following:
Last updated