Federated authentication lets users log in using accounts from other trusted services. This makes signing in easier and safer.
Federated authentication in GraphQL
Start learning this pattern below
Jump into concepts and practice - no test required
type Query {
currentUser: User
}
type User {
id: ID!
name: String!
email: String!
}
# Authentication handled outside GraphQL, e.g., via OAuth tokens passed in headersGraphQL itself does not define authentication; it relies on external systems.
Federated authentication usually uses tokens (like OAuth) sent in request headers.
# Example query to get current user info after federated login
query {
currentUser {
id
name
email
}
}# Example of sending OAuth token in HTTP header Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
This query returns the current user's ID, name, and email after successful federated authentication.
# Query to get current user info
query {
currentUser {
id
name
email
}
}Federated authentication is handled outside GraphQL, often by middleware or API gateways.
GraphQL queries use the authentication info to return data for the logged-in user.
Always secure tokens and never expose them in client-side code.
Federated authentication lets users sign in using trusted external accounts.
GraphQL queries use tokens from federated login to identify users.
This improves security and user experience by avoiding password management.
Practice
Solution
Step 1: Understand federated authentication purpose
Federated authentication lets users log in using accounts from trusted external providers like Google or Facebook.Step 2: Identify the benefit in GraphQL context
This avoids the need for users to create and remember new passwords for each app, improving security and convenience.Final Answer:
Users can sign in using trusted external accounts without managing passwords. -> Option CQuick Check:
Federated authentication = external login without passwords [OK]
- Thinking federated auth stores passwords locally
- Confusing federated auth with anonymous access
- Assuming it forces new passwords for each app
Solution
Step 1: Recall standard token header format
Federated authentication tokens are usually sent in the HTTP header as "Authorization: Bearer <token>".Step 2: Compare options to standard
Only "Authorization: Bearer <token>" matches the standard format exactly.Final Answer:
"Authorization: Bearer <token>" -> Option DQuick Check:
Auth header = Authorization: Bearer token [OK]
- Using wrong header names like Auth-Token
- Swapping 'Bearer' and 'Token' keywords
- Adding extra words in header key
query {
currentUser {
id
email
name
}
}
Assuming the token identifies user with id=42, email='user@example.com', and name='Alice'.Solution
Step 1: Understand token identifies user
The federated token corresponds to user with id=42, email='user@example.com', and name='Alice'.Step 2: Query requests currentUser fields
The query asks for id, email, and name of the authenticated user, so these values will be returned.Final Answer:
{ "data": { "currentUser": { "id": 42, "email": "user@example.com", "name": "Alice" } } } -> Option BQuick Check:
Token user info = query result [OK]
- Expecting null or error despite valid token
- Confusing error response with data
- Assuming fields return null values
Solution
Step 1: Identify cause of Unauthorized error
Unauthorized usually means missing or invalid authentication token in the request.Step 2: Apply correct token header format
Adding the token properly as "Authorization: Bearer <token>" header will authenticate the user and fix the error.Final Answer:
Add the token in the request header as "Authorization: Bearer <token>". -> Option AQuick Check:
Unauthorized error = missing or wrong token header [OK]
- Removing token expecting anonymous access
- Changing query without fixing auth
- Using wrong header names or formats
Solution
Step 1: Understand multi-provider federated auth challenge
Users may log in via different providers but represent the same person, so linking identities is needed.Step 2: Choose best identity mapping strategy
Mapping external provider IDs to a single internal user ID lets the system recognize the same user regardless of provider.Final Answer:
Map external provider user IDs to a single internal user ID in your database. -> Option AQuick Check:
Link multiple provider IDs to one internal user [OK]
- Creating separate users per provider causing duplicates
- Relying only on email which may not be unique or verified
- Forcing manual linking which hurts user experience
