feat: add @ascorbic/atproto-oauth-provider package

[ascorbic]

Implement OAuth 2.1 provider with AT Protocol extensions:

• PKCE verification (S256 method)
• DPoP proof verification using jose library (RFC 9449)
• Pushed Authorization Requests (PAR) handler (RFC 9126)
• DID-based client discovery
• Token generation and validation
• Authorization consent UI
• Core OAuth provider class orchestrating the flow

All 49 tests pass covering:

• PKCE challenge generation and verification
• DPoP proof verification with key thumbprint
• PAR push and retrieve flow
• Full OAuth authorization code flow with DPoP

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	atproto-pds	7bb1ae4	Dec 30 2025, 08:50 PM

[Copilot]

Pull request overview

This PR introduces a comprehensive OAuth 2.1 provider package (@ascorbic/atproto-oauth-provider) with AT Protocol extensions, implementing PKCE verification (S256), DPoP proof verification (RFC 9449), and Pushed Authorization Requests (RFC 9126). The implementation includes DID-based client discovery, token generation/validation, authorization consent UI, and full integration with the PDS via Durable Objects. All 49 tests pass, covering PKCE, DPoP, PAR, and the complete OAuth authorization code flow.

Key changes:

• New packages/oauth-provider package with modular OAuth components (provider, storage, PKCE, DPoP, PAR, client resolver)
• PDS integration via oauth.ts with DO-proxy storage and OAuth endpoints
• SQLite-backed OAuth storage in Durable Objects with automatic cleanup
• Authorization consent UI with CSP headers and XSS protection

Reviewed changes

Copilot reviewed 26 out of 27 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
packages/oauth-provider/package.json	New package definition with dependencies on @atproto/oauth-types, @atproto/syntax, and jose
packages/oauth-provider/src/provider.ts	Core OAuth 2.1 provider orchestrating authorization code flow with PKCE, DPoP, and PAR
packages/oauth-provider/src/pkce.ts	PKCE verification implementation with S256 challenge method (RFC 7636)
packages/oauth-provider/src/dpop.ts	DPoP proof verification using jose library (RFC 9449) with key thumbprint calculation
packages/oauth-provider/src/par.ts	PAR handler implementing RFC 9126 for pushed authorization requests
packages/oauth-provider/src/tokens.ts	Opaque token generation and validation with configurable TTLs
packages/oauth-provider/src/storage.ts	Storage interface and in-memory implementation for testing
packages/oauth-provider/src/client-resolver.ts	DID-based client metadata resolution with caching
packages/oauth-provider/src/ui.ts	Authorization consent UI with XSS protection and CSP headers
packages/oauth-provider/src/encoding.ts	Shared encoding utilities using jose's base64url
packages/oauth-provider/src/index.ts	Package exports for public API
packages/pds/src/oauth.ts	OAuth routes integration with PDS via DO-proxy storage
packages/pds/src/oauth-storage.ts	SQLite OAuth storage implementation for Durable Objects
packages/pds/src/account-do.ts	RPC methods added for OAuth storage operations
packages/pds/src/index.ts	OAuth routes mounted to main app
packages/oauth-provider/test/*.test.ts	Comprehensive tests for PKCE, DPoP, PAR, and full OAuth flow
packages/pds/test/oauth.test.ts	Integration tests for PDS OAuth endpoints
pnpm-lock.yaml	Dependency updates including new @atproto packages and jose library

Files not reviewed (1)

• pnpm-lock.yaml: Language not supported

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The comment numbering skips from step 7 to step 9. Step 8 is missing. This should be renumbered for clarity and consistency.

Suggested change

	// 9. Cache metadata
	// 8. Cache metadata

[Copilot]

Using setTimeout in the InMemoryOAuthStorage implementation is problematic for testing and Cloudflare Workers environments. In Workers, there's no guarantee that the setTimeout callback will execute if the Worker is idle, and timers can accumulate without cleanup. For a test-only implementation, consider either accepting that this is a limitation or documenting that cleanup should be done explicitly via the clear() method. In production, this should be handled by the SQLite storage cleanup() method instead.

[Copilot]

The revokeToken method only revokes by access token, but the token revocation endpoint (RFC 7009) accepts either access or refresh tokens. The OAuth revocation endpoint in oauth.ts passes the token parameter directly to rpcRevokeToken, which means refresh token revocations won't work. Consider adding logic to check both token types or renaming the method to clarify it only handles access tokens.

[Copilot]

The token revocation endpoint accepts requests with empty bodies and returns success per RFC 7009 (line 200-201), but it also tries to parse the body first (lines 178-196) which may throw an error. If the Content-Type header is application/json or application/x-www-form-urlencoded but the body is empty, the parsing will succeed and token will be undefined, which is correctly handled. However, if the Content-Type is missing or invalid, the error response at lines 187-190 will be returned instead of the success response required by RFC 7009. Consider handling missing/invalid Content-Type more gracefully for empty bodies.

[Copilot]

The comment numbering skips from step 1 to step 3. Step 2 is missing. This should be renumbered for clarity and consistency.

Suggested change

	// 3. Validate client_id is present
	const clientId = params.client_id;
	if (!clientId) {
	return this.errorResponse("invalid_request", "Missing client_id parameter", 400);
	}
	// 4. Validate required OAuth parameters
	for (const param of REQUIRED_PARAMS) {
	if (!params[param]) {
	return this.errorResponse("invalid_request", `Missing required parameter: ${param}`, 400);
	}
	}
	// 5. Validate response_type is "code"
	// 2. Validate client_id is present
	const clientId = params.client_id;
	if (!clientId) {
	return this.errorResponse("invalid_request", "Missing client_id parameter", 400);
	}
	// 3. Validate required OAuth parameters
	for (const param of REQUIRED_PARAMS) {
	if (!params[param]) {
	return this.errorResponse("invalid_request", `Missing required parameter: ${param}`, 400);
	}
	}
	// 4. Validate response_type is "code"

[Copilot]

Unused variable state.

[Copilot]

Unused variable refreshTokenTtl.

Suggested change

refreshTokenTtl = REFRESH_TOKEN_TTL,

[Copilot]

Pull request overview

Copilot reviewed 31 out of 32 changed files in this pull request and generated 4 comments.

Files not reviewed (1)

• pnpm-lock.yaml: Language not supported

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The comment on line 8 mentions that the package contains a SQL connection that can't be serialized, but this comment is describing SqliteOAuthStorage, not the DOProxyOAuthStorage class. The phrasing "This is needed because the SqliteOAuthStorage object contains a SQL connection" is slightly unclear - consider rephrasing to "This is needed because SqliteOAuthStorage instances contain a SQL connection that can't be serialized across the DO RPC boundary."

Suggested change

	* This is needed because the SqliteOAuthStorage object contains a SQL connection
	* that can't be serialized across the DO RPC boundary. Instead, we delegate each
	* storage operation to individual RPC methods that pass serializable data.
	* This is needed because SqliteOAuthStorage instances contain a SQL connection
	* that can't be serialized across the DO RPC boundary. Instead, we delegate each
	* storage operation to individual RPC methods that pass only serializable data.

[Copilot]

The CSP on line 18-19 allows 'unsafe-inline' for styles, which could be avoided by moving the CSS to an external file or using a nonce/hash-based approach. While this is acceptable for a consent UI with inline styles, consider documenting why inline styles are necessary here, or exploring safer alternatives if this UI will be extended in the future.

[Copilot]

The check on line 176 rejects requests where ath is present but no accessToken was provided for verification. However, according to RFC 9449 Section 4.3, the ath claim is only required when presenting an access token to a resource server, not at the token endpoint. This logic will incorrectly reject valid DPoP proofs at the token endpoint that don't include ath (which is correct behavior for token endpoint requests). Consider removing this check or making it conditional based on whether an access token is expected in the context.

Suggested change

	} else if (payload.ath !== undefined) {
	throw new DpopError('DPoP "ath" claim not allowed without access token', "invalid_dpop");

[Copilot]

The error message on line 197 states "Content-Type must be application/json or application/x-www-form-urlencoded", but according to RFC 7009 Section 2.1, the token revocation endpoint should accept application/x-www-form-urlencoded as the required content type. While accepting JSON is a reasonable extension, the current implementation returns an error for missing Content-Type headers even when the body might be empty (which is handled at line 208). Consider either removing the Content-Type requirement for empty bodies, or clarifying that JSON is an extension to the standard.

Suggested change

	} else {
	return c.json(
	{ error: "invalid_request", error_description: "Content-Type must be application/json or application/x-www-form-urlencoded" },
	} else if (!contentType && (!c.req.header("Content-Length") || c.req.header("Content-Length") === "0")) {
	// No Content-Type and no body: treat as no token provided (RFC 7009 allows this)
	token = undefined;
	} else {
	return c.json(
	{
	error: "invalid_request",
	error_description:
	"Content-Type must be application/x-www-form-urlencoded (per RFC 7009) or application/json",
	},