cloudflare / cloudflare/workers-oauth-provider
docs: 0.x to 1.0 migration guide
- Dominant language
- TypeScript
- Stars
- 1.9k
- Forks
- 134
- PR merge metrics
- No merged PRs in 30d
Description
## Summary
Write a human-facing migration guide for upgrading from 0.x to 1.0. This is the document a developer reads before touching their Worker. It is also the source that the agent migration skill and the codemod CLI are derived from, so it has to be complete and precise about every breaking change.
## Scope
Cover every breaking change that lands in 1.0. As of #289 and #292 that is:
- `resourceMetadata` and `resourceMetadata.resource` become required (#289).
- `resourceMatchOriginOnly` is removed, and a configuration that still sets it fails at construction (#289).
- Every `apiRoute` and `apiHandlers` key must be the canonical resource path or a descendant of it; anything else fails at construction (#289).
- External token resolvers must return the canonical audience (#289).
- Token exchange and protected-resource access require the registered canonical audience (#289).
- Token exchange is bound to the client the grant was issued to unless `tokenExchangeCallback` returns `allowCrossClientExchange: true`; the callback receives `subjectClientId`; subject-token failures return `invalid_request` (#289).
- Registered `grant_types` are enforced at the token endpoint with `unauthorized_client`; `refresh_token` is implied by `authorization_code`; token exchange must be registered explicitly (#210, landed in #289).
- Grants are replaced per user + client + resource instead of per user + client (#289).
- `OAuthAuthorizationServer` takes `resources` at construction; `registerResource()` and the three-argument `validateToken()` are gone in favor of `resource(uri)` handles (#289).
- Plain `http` identifiers require `allowHttp: true`, intended for `wrangler dev` (#289).
- Public type changes: `ExchangeTokenOptions.aud`, `AuthRequest.resource`, and `TokenExchangeCallbackOptions.resource` are single strings; `ResolveExternalTokenResult.audience` is required (#289).
- Any stored-data changes from the grant index work in #232.
Then the new deployment shapes:
- Single Worker AS + RS using the existing `OAuthProvider` API. Show the minimal diff from a 0.x config. This is the shape most users are on and the one the codemod targets.
- One AS Worker serving multiple resources with `OAuthAuthorizationServer`, `protectResource()` and `registerResource()`.
- Separate RS Worker with `createOAuthResourceServer()`, validating over a Service Binding.
- Separate RS Worker validating offline with JWT access tokens and JWKS (#292), including the opaque-to-JWT rollout and rollback steps already described in that PR.
## Behavioral migration notes
- What happens to pre-1.0 grants and access tokens with no stored resource. They keep working: an access token with no audience is treated as bound to the sole resource (or `legacyGrantResource`) until it expires; refresh binds the grant and returns a bound token; a stored array that contains the registered resource resolves to it; a grant bound only to unregistered resources fails its refresh with `invalid_grant`, which the MCP SDK answers with a fresh authorization. Restate these in terms of what a user sees.
- What happens to existing refresh tokens and authorization codes.
- What clients like Claude, ChatGPT, Claude Code, Codex and the MCP Server Portal send today, and which of the above rules each one exercises.
## Deliverable
- `docs/migration-1.0.md`, linked from the README and the 1.0 changelog entry.
- A short "Am I affected" checklist at the top so users on the default single-Worker shape can confirm the diff is small.
## Related
- Agent skill for the migration: derived from this document.
- Codemod CLI: automates the single-Worker case described here.
Contributor guide
Research direction
Start by reviewing the breaking-change references in #289, #292, and #232, then inspect the existing OAuthProvider, OAuthAuthorizationServer, protectResource(), registerResource(), and createOAuthResourceServer() APIs. Write docs/migration-1.0.md with the affected-user checklist, migration shapes, behavioral notes, and rollout steps. Done means it is linked from the README and 1.0 changelog and is precise enough to derive the agent skill and codemod.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- authentication, documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 45/100