Why Federated authentication in GraphQL? - Purpose & Use Cases

The Big Idea

What if you could log in everywhere with just one click, no passwords to remember?

The Scenario

Imagine you have multiple apps and websites, each needing users to log in separately with different usernames and passwords. You have to remember many passwords or write them down somewhere.

The Problem

This manual way is slow and frustrating. Users forget passwords, create weak ones, or reuse them everywhere, risking security. Developers must build and maintain many login systems, which is error-prone and costly.

The Solution

Federated authentication lets users log in once using a trusted service like Google or Facebook. Apps trust that service to confirm identity, so users don't need multiple passwords. It's faster, safer, and easier for everyone.

Before vs After

✗ Before

mutation { login(username: "user", password: "pass") { token } }

✓ After

mutation { federatedLogin(provider: "Google", token: "abc123") { token } }

What It Enables

It enables seamless, secure access across many apps with just one login from a trusted identity provider.

Real Life Example

When you use your Google account to sign into a new app without creating a new password, that's federated authentication in action.

Key Takeaways

Manual logins are hard to manage and insecure.

Federated authentication simplifies login by using trusted providers.

This improves security and user experience across apps.

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