access_token, id_token and the Userinfo endpoint

The problem

After a successful login, the Chrome Extension showed a green indicator. Logged in, but no email address. The React frontend displayed the fallback value "Dev-Nutzer" instead of the user’s name.

The code looked correct. It requested the openid profile email scopes. It received the token. But the email field was empty.

The cause was that the code read email from the access token. Zitadel puts the email address in the ID token, but only if that address has been verified.

This is not a Zitadel bug. It is how OIDC is designed.

Two tokens, two purposes

OAuth 2.0 and OIDC return at least two tokens after a successful login:

The access_token is proof of authorization for resources. The backend validates it against the identity provider’s JWKS endpoint on every API call. It answers the question: “Does this caller have permission to retrieve this resource?”

The id_token is proof of identity. It answers the question: “Who just logged in?” It belongs to the frontend, not the backend.

Why OIDC separates profile data

A JWT passes through many places: the URL fragment during a redirect, browser history, server logs, referrer headers and load balancer logs. The more personal data a JWT contains, the greater the risk if it leaks.

OIDC addresses this as follows:

• The id_token contains only the minimum needed for login (sub, iss, aud, exp)
• Additional profile data (email, name, phone_number) comes from the Userinfo endpoint
• The Userinfo endpoint is called through a direct HTTPS request. It never appears in logs or URLs

This is not a theoretical detail. The distinction matters for GDPR-compliant systems: personal data should appear in transit as little as possible.

The Userinfo endpoint

Every OIDC-compliant identity provider exposes a Userinfo endpoint. In Zitadel:

GET /oidc/v1/userinfo
Authorization: ******

Here, the access_token provides authorization. Rather than protecting an external resource, the endpoint returns the current user’s own profile. The identity provider validates the token and returns only data belonging to its holder. You cannot use your token to retrieve another user’s profile.

The response contains all claims defined by the requested scopes (profile, email):

{
  "sub": "374907089107025923",
  "email": "user@example.com",
  "email_verified": true,
  "preferred_username": "user@example.com",
  "name": "Max Mustermann",
  "given_name": "Max",
  "family_name": "Mustermann"
}

What this looks like in practice

The React frontend and the extension retrieve these profile claims in different ways.

React frontend with react-oidc-context

By default, react-oidc-context decodes the id_token locally and exposes its claims through auth.user.profile. That is not enough for Zitadel, because email may be absent from the id_token.

The solution is loadUserInfo: true in the OIDC configuration:

// frontend/src/lib/auth.ts
export const oidcConfig: AuthProviderProps = {
  authority: ZITADEL_DOMAIN,
  client_id: CLIENT_ID,
  scope: 'openid profile email offline_access',
  // Fetch /oidc/v1/userinfo after login and merge claims into auth.user.profile.
  // Reliable for email even when the address is unverified in Zitadel.
  loadUserInfo: true,
  // ...
};

After this change, auth.user.profile.email is always populated. The library automatically calls the Userinfo endpoint after login and merges the claims.

Chrome Extension with a manual PKCE flow

The extension manages tokens itself through chrome.storage.sync. After exchanging the code for tokens, it calls the Userinfo endpoint directly:

// extension/src/auth/zitadel.ts

async function fetchUserEmail(accessToken: string): Promise<string> {
  try {
    const res = await fetch(`${ZITADEL_DOMAIN}/oidc/v1/userinfo`, {
      headers: { Authorization: `****** },
    });
    if (!res.ok) return "";
    const profile = (await res.json()) as Record<string, unknown>;
    return (profile.email as string) ?? (profile.preferred_username as string) ?? "";
  } catch {
    return "";
  }
}

async function exchangeCodeForTokens(/* ... */): Promise<StoredTokens> {
  // ... token exchange ...
  const email = await fetchUserEmail(data.access_token);
  return { accessToken, refreshToken, expiresAt, userId, email };
}

During a token refresh, Zitadel does not return a new id_token. Calling Userinfo with the new access_token still works. The email stored after the last successful login acts as a fallback:

const email = (await fetchUserEmail(data.access_token)) || existingTokens?.email || '';

Is this secure?

Yes. Authorizing the Userinfo endpoint with the access_token is exactly what the OIDC Core standard specifies in section 5.3. It is not a workaround.

The important security points:

• The access_token is short-lived, typically one hour. The identity provider immediately rejects an expired token
• The Userinfo endpoint is read-only and returns only the token holder’s data
• The request is a direct HTTPS fetch. It does not enter browser history or URL logs
• The access_token must not be stored in localStorage because of the XSS attack surface. The frontend configuration therefore uses sessionStorage (userStore: undefined in react-oidc-context)

The only drawback is one extra HTTP request after login. For an application that logs in once and then runs for hours, that is negligible.

What changed

The error was in the mental model, not the code. Reading email from the access_token or id_token relies on an implementation detail of the identity provider. The Userinfo endpoint provides the guarantee, specified in the standard and consistent across OIDC providers.

The rule is straightforward:

Send access_token to the backend. Use id_token minimally for session management. Always retrieve profile data from the Userinfo endpoint.

All articles in the series

1. Vision and system overview: Chrome Extension, RAG architecture and project background: Read article
2. Building a RAG system: Qdrant, embeddings and cosine similarity in TypeScript: Read article
3. AI provider abstraction: Ollama vs. OpenAI, interface design and no vendor lock-in: Read article
4. Chrome Extension MV3: Three isolated runtime contexts, message passing and Strategy Pattern: Read article
5. Docker Compose strategy: The override pattern, from local development to Azure: Read article
6. Ollama locally vs. Docker: The decision and its consequences: Read article
7. Ollama auto-pull entrypoint: Automated model setup at container startup: Read article
8. tsconfig and Vite: Node16 vs. bundler, and why Vite has its own rules: Read article
9. Load complete Instagram captions with MutationObserver: Read article
10. Chrome Extension foundation with health indicator and retry queue: Read article
11. Phase 2 features: Shadow DOM overlay, Tailwind v4 and duplicate detection: Read article
12. Race condition in platform detection: How a UI event breaks Instagram detection: Read article
13. Extracting PostId in two Instagram layouts: querySelector vs. ancestor traversal: Read article
14. Capture a complete Instagram carousel with MutationObserver: Lazy loading, observer-before-click and timeout fallback: Read article
15. Notes and tags when saving screenshots: Read article
16. Instagram keyboard shortcuts block Chrome Extension input: Read article
17. Lowercase normalization and duplicate detection in tag input: Read article
18. Zitadel Login V2 in Docker Compose with three hidden errors: Read article
19. PKCE OAuth in a Chrome MV3 extension: Read article
20. React frontend with react-oidc-context and Zitadel: Read article
21. Vite build-time environment variables in Docker: Read article
22. Event-driven ingestion with BullMQ and Redis: Read article
23. MinIO instead of Azurite: S3-compatible object storage locally and on Hetzner: Read article
24. access_token, id_token and the Userinfo endpoint: Which belongs where: (this article)
25. Qdrant multi-tenancy with one collection per user: Read article
26. When backend and frontend know different types: Read article
27. Removing Zitadel bootstrap: Host header bug and manual setup: Read article
28. Backend code review with six problems fixed before launch: Read article
29. Traefik instead of NGINX: Reverse proxy for a growing Docker Compose stack: Read article
30. Two-layer rate limiting: Traefik and express-rate-limit with Redis: Read article
31. Implementing GDPR Article 17 correctly: Promise.allSettled and export batching: Read article
32. Embedding model lock-in: Why mxbai-embed-large is a permanent production decision: Read article
33. Docker volumes in production: Named volumes, bind mounts and the Hetzner volume approach: Read article
34. Two vulnerabilities before launch: Redis without authentication and an exposed Qdrant admin port: Read article
35. Traefik as the single entry point in the Docker Compose stack: Read article
36. Connecting Zitadel behind Traefik with issuer, JWKS and Login V2: Read article
37. Fixing the frontend when the nginx healthcheck fails on localhost: Read article
38. Observability for my Docker Compose stack with Bull Board and Dozzle: Read article
39. Open the Qdrant dashboard securely with local Traefik and an SSH tunnel: Read article
40. Diagnosis of chunking failures despite tokenization: Read article
41. Why I set the chunk size to 1500 tokens: Read article
42. Splitting the embedding workflow into clear steps: Read article
43. Bringing chunking, storage and search back together: Read article
44. Capture Intake as a separate module, less orchestration in the Express endpoint: Read article

Are you building a system with OIDC and wondering which token belongs where? Let us look at it together.