example: Apollo Client with Application Passwords (server-side) #44

Overview

An example showing how to authenticate Apollo Client with a WordPress Application Password, server-side only.

This mirrors what Faust.js now does: wpengine/faustjs#2676 replaced FAUST_SECRET_KEY with FAUST_APPLICATION_USER / FAUST_APPLICATION_PASSWORD (sent as Basic auth) for the token exchange, logout, and CLI commands like generatePossibleTypes. wpengine/faustjs#2673 documents server-side writes with an Application Password and a scoped role. This example should show the same pattern without Faust.

Acceptance Criteria

• Credentials come from WP_APPLICATION_USER / WP_APPLICATION_PASSWORD env vars and are only used in server code (server components, route handlers or getServerSideProps); they are never exposed to the browser
• An Apollo link that adds the Authorization: Basic header on the server
• A codegen step that generates possibleTypes (and TS types) via introspection using the same credentials; examples/next/apollo-authentication/example-app/codegen.ts is a starting point
• The Application Password belongs to a scoped role/user rather than an administrator, following the approach in docs: explain server-side writes with Application Passwords and a scoped role faustjs#2673
• README explains why Application Passwords must stay server-side

Notes

• Authenticated requests shouldn't go through GET / persisted-query caching, so auth with persisted queries is out of scope; the README can briefly explain why.
• This covers site-level credentials (the server talks to WordPress as a single service account). For per-user login (visitors sign in), see example: Fetch client example showing auth for app router #45. Each README should point to the other.