Federated authentication in GraphQL - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the main purpose of federated authentication?

Choose the best description of federated authentication.

A It stores all user passwords in a single database for easy access.

B It encrypts user data locally on their device before sending it to the server.

C It requires users to create new accounts for every service they use.

D It allows users to log in using credentials from multiple trusted identity providers.

💡 Hint

Think about how users can use one login for many services.

Federated authentication lets users sign in with one account from a trusted provider, like Google or Facebook, to access multiple services without creating new passwords.

❓ query_result

intermediate

What is the output of this GraphQL query for federated user info?

Given this GraphQL query requesting user email and provider, what is the expected JSON response?

GraphQL

query {
  user(id: "123") {
    email
    authProvider
  }
}

A { "data": { "user": { "email": "[e-mail]", "authProvider": "Google" } } }

B { "data": { "user": { "email": null, "authProvider": null } } }

C { "error": "User not found" }

D { "data": { "user": { "email": "[e-mail]" } } }

💡 Hint

The user exists and uses Google as their login provider.

The query requests both email and authProvider fields. The user exists, so both fields return valid values.

📝 Syntax

advanced

Which GraphQL schema snippet correctly defines a federated user type with an external key?

Select the valid GraphQL SDL code that defines a federated User type with an external key.

A

type User @key(fields: "id") {
  id: ID!
  email: String
  authProvider: String
}

B

type User @external(fields: "id") {
  id: ID!
  email: String
  authProvider: String
}

C

type User @key(fields: id) {
  id: ID!
  email: String
  authProvider: String
}

D

type User @key(fields: "id") {
  id: ID
  email: String
  authProvider: String
}

💡 Hint

The @key directive requires quoted field names and non-null id.

The @key directive must have quoted field names. The id field must be non-nullable (ID!). Option A follows both rules.

❓ optimization

advanced

How to optimize federated GraphQL queries to reduce data fetching overhead?

Which approach best reduces unnecessary data fetching in a federated GraphQL service?

A Fetch all fields from every service regardless of query to cache data.

B Disable query batching to send each request separately for clarity.

C Use @requires directive to specify dependent fields and avoid fetching unrelated data.

D Use multiple nested queries to fetch data from each service independently.

💡 Hint

Think about how to tell the gateway what fields are needed for resolving.

The @requires directive helps specify which fields are needed from other services, so the gateway fetches only necessary data, improving efficiency.

🔧 Debug

expert

Why does this federated GraphQL query fail with a 'Cannot query field' error?

Given this query: query { user(id: "123") { id email profilePicture } } And the User type schema: type User @key(fields: "id") { id: ID! email: String } Why does querying profilePicture cause an error?

A The id field is missing from the query, causing the error.

B The profilePicture field is not defined in the User type schema, so it cannot be queried.

C The @key directive is incorrectly used and causes all fields to be inaccessible.

D The user id "123" does not exist, so no fields can be queried.

💡 Hint

Check if the requested field exists in the schema.

The error occurs because profilePicture is not declared in the User type schema, so GraphQL rejects the query for that field.

Practice

1. What is the main benefit of federated authentication in GraphQL applications?

easy

A. It allows anonymous access without any login.

B. It stores all user passwords securely in the GraphQL server.

C. Users can sign in using trusted external accounts without managing passwords.

D. It requires users to create new passwords for each service.

Solution

1. Step 1: Understand federated authentication purpose

   Federated authentication lets users log in using accounts from trusted external providers like Google or Facebook.

2. 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.

3. Final Answer:

   Users can sign in using trusted external accounts without managing passwords. -> Option C

4. Quick Check:

   Federated authentication = external login without passwords [OK]

Hint: Federated means login via trusted external accounts [OK]

Common Mistakes:

• Thinking federated auth stores passwords locally
• Confusing federated auth with anonymous access
• Assuming it forces new passwords for each app

2. Which of the following is the correct way to include a federated authentication token in a GraphQL request header?

easy

A. "Token: Bearer <token>"

B. "Auth-Token: <token>"

C. "Bearer-Authorization: <token>"

D. "Authorization: Bearer <token>"

Solution

1. Step 1: Recall standard token header format

   Federated authentication tokens are usually sent in the HTTP header as "Authorization: Bearer <token>".

2. Step 2: Compare options to standard

   Only "Authorization: Bearer <token>" matches the standard format exactly.

3. Final Answer:

   "Authorization: Bearer <token>" -> Option D

4. Quick Check:

   Auth header = Authorization: Bearer token [OK]

Hint: Use 'Authorization: Bearer <token>' header format [OK]

Common Mistakes:

• Using wrong header names like Auth-Token
• Swapping 'Bearer' and 'Token' keywords
• Adding extra words in header key

3. Given this GraphQL query with federated authentication token, what user information will be returned?

query {
  currentUser {
    id
    email
    name
  }
}

Assuming the token identifies user with id=42, email='[e-mail]', and name='Alice'.

medium

A. { "data": { "currentUser": { "id": null, "email": null, "name": null } } }

B. { "data": { "currentUser": { "id": 42, "email": "[e-mail]", "name": "Alice" } } }

C. { "errors": [ { "message": "Unauthorized" } ] }

D. { "data": { "currentUser": null } }

Solution

1. Step 1: Understand token identifies user

   The federated token corresponds to user with id=42, email='[e-mail]', and name='Alice'.

2. Step 2: Query requests currentUser fields

   The query asks for id, email, and name of the authenticated user, so these values will be returned.

3. Final Answer:

   { "data": { "currentUser": { "id": 42, "email": "[e-mail]", "name": "Alice" } } } -> Option B

4. Quick Check:

   Token user info = query result [OK]

Hint: Token user data matches currentUser fields returned [OK]

Common Mistakes:

• Expecting null or error despite valid token
• Confusing error response with data
• Assuming fields return null values

4. A developer tries to use federated authentication but gets an "Unauthorized" error. Which fix will most likely solve the problem?

medium

A. Add the token in the request header as "Authorization: Bearer <token>".

B. Remove the token from the request to allow anonymous access.

C. Change the query to request only public fields.

D. Use a different GraphQL query without authentication.

Solution

1. Step 1: Identify cause of Unauthorized error

   Unauthorized usually means missing or invalid authentication token in the request.

2. Step 2: Apply correct token header format

   Adding the token properly as "Authorization: Bearer <token>" header will authenticate the user and fix the error.

3. Final Answer:

   Add the token in the request header as "Authorization: Bearer <token>". -> Option A

4. Quick Check:

   Unauthorized error = missing or wrong token header [OK]

Hint: Always send token in Authorization header [OK]

Common Mistakes:

• Removing token expecting anonymous access
• Changing query without fixing auth
• Using wrong header names or formats

5. You want to implement federated authentication in a GraphQL API that supports multiple identity providers (Google, Facebook, GitHub). Which approach best handles user identity across these providers?

hard

A. Map external provider user IDs to a single internal user ID in your database.

B. Create separate user records for each provider's user ID without linking.

C. Require users to manually link accounts after login.

D. Ignore provider IDs and use only email addresses to identify users.

Solution

1. 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.

2. 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.

3. Final Answer:

   Map external provider user IDs to a single internal user ID in your database. -> Option A

4. Quick Check:

   Link multiple provider IDs to one internal user [OK]

Hint: Link all provider IDs to one internal user ID [OK]

Common Mistakes:

• 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