Federated authentication in GraphQL - Step-by-Step Execution

Concept Flow - Federated authentication

User tries to access app

↓

App redirects to Identity Provider (IdP)

↓

User logs in at IdP

↓

IdP sends token to app

↓

App verifies token

↓

Access granted if token valid

↓

User accesses resources

User tries to log in, app sends them to a trusted identity provider. After login, the provider sends a token back. The app checks the token and grants access if valid.

Execution Sample

GraphQL

query GetUserData {
  user {
    id
    name
    email
  }
}

A GraphQL query to get user data after federated authentication is successful.

Execution Table

Step	Action	Input/Condition	Output/Result
1	User requests access	User opens app	App redirects to IdP login page
2	User logs in	User enters credentials at IdP	IdP authenticates user
3	IdP sends token	User authenticated	Token sent to app
4	App verifies token	Token received	Token valid? Yes
5	App executes GraphQL query	Valid token	User data returned
6	User accesses resources	User data received	Access granted

💡 Process stops if token is invalid or user cancels login

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
user_authenticated	false	true	true	true	true
token	null	null	token_string	token_string	token_string
access_granted	false	false	false	true	true

Key Moments - 2 Insights

Why does the app redirect the user to the Identity Provider instead of asking for credentials directly?

Because the app trusts the Identity Provider to handle authentication securely. This is shown in execution_table step 1 where the app redirects to IdP.

What happens if the token sent by the Identity Provider is invalid?

The app will not grant access and the process stops. This is implied in the exit_note and step 4 where token validity is checked.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the app receive the token?

A Step 3

B Step 4

C Step 2

D Step 5

💡 Hint

Check the 'Action' and 'Output/Result' columns in execution_table row for Step 3

According to variable_tracker, when does 'access_granted' become true?

A After Step 3

B After Step 4

C After Step 2

D At Start

💡 Hint

Look at the 'access_granted' row and see when it changes from false to true

If the token was invalid, what would happen to 'user_authenticated' in variable_tracker?

A It would become true

B It would become null

C It would remain false

D It would be removed

💡 Hint

user_authenticated becomes true after Step 2 when IdP authenticates, before token verification. See variable_tracker.

Concept Snapshot

Federated authentication lets users log in via a trusted external provider.
The app redirects users to the provider for login.
The provider sends back a token after successful login.
The app verifies the token before granting access.
This keeps user credentials safe and centralized.

Full Transcript

Federated authentication is a process where a user tries to access an app, which then redirects the user to a trusted identity provider for login. The user enters credentials at the identity provider, which authenticates the user and sends back a token to the app. The app verifies this token and if valid, grants access to the user. This process ensures secure login without the app handling user passwords directly. The GraphQL query example shows how after authentication, the app can request user data securely. Variables like user_authenticated and access_granted track the login state. If the token is invalid, access is denied and the process stops.

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