Federated authentication in GraphQL - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to specify the authentication provider in the GraphQL schema directive.

GraphQL

type Query @auth(provider: "[1]") { user: User }

Drag options to blanks, or click blank then click option'

Atwitter

Bfacebook

Clocal

Dgoogle

Attempts:

3 left

💡 Hint

Common Mistakes

Using a provider name that is not supported or misspelled.

Confusing local authentication with federated providers.

The @auth directive uses the provider argument to specify which federated authentication provider to use. Here, "google" is the correct provider name.

2fill in blank

medium

Complete the code to request the user's email from the federated authentication token.

GraphQL

query getUser { user(email: [1]) { id name } }

Drag options to blanks, or click blank then click option'

A"auth.email"

B"token.email"

C"context.email"

D"user.email"

Attempts:

3 left

💡 Hint

Common Mistakes

Using incorrect variable names that do not exist in the query context.

Assuming the email is directly under 'user' or 'token' without context.

In federated authentication, the user's email is often accessed from the context object that holds the authentication token data.

3fill in blank

hard

Fix the error in the authentication directive by completing the missing argument.

GraphQL

type Mutation @auth([1]: "github") { updateUser(name: String): User }

Drag options to blanks, or click blank then click option'

Aprovider

Btoken

Cscope

Drole

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'token' or 'scope' which are not valid directive arguments here.

Omitting the argument name entirely.

The @auth directive requires the provider argument to specify the federated authentication service.

4fill in blank

hard

Fill both blanks to complete the federated authentication header and token extraction.

GraphQL

headers: { Authorization: "Bearer [1]" }, context: { user: [2] }

Drag options to blanks, or click blank then click option'

Aaccess_token

BauthToken

Ctoken

DuserToken

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing up token variable names causing authentication failure.

Using incorrect header formats.

The Authorization header uses the token value, and the context user is extracted from authToken.

5fill in blank

hard

Fill all three blanks to complete the federated authentication resolver with token validation and user extraction.

GraphQL

resolve(parent, args, context) { const [1] = context.headers["[2]"];
 if (![1]) throw new Error("No token");
 return getUserFromToken([1]); }

Drag options to blanks, or click blank then click option'

AauthToken

BAuthorization

Ctoken

DaccessToken

Attempts:

3 left

💡 Hint

Common Mistakes

Using lowercase 'authorization' which may cause header lookup failure.

Using different variable names for token extraction and usage.

The resolver extracts the token from the 'Authorization' header into the variable 'authToken' and uses it to get the user.

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