Atproto Oauth Bundle Laravel Package

Product Decisions This Supports

• "Sign in with Bluesky" / AT Protocol identity as a login option. This package covers the whole confidential-client OAuth flow (PAR, PKCE S256, DPoP with server nonces, private_key_jwt ES256), so the decision "do we support Bluesky as an identity provider?" becomes a days-not-months estimate rather than a research spike.
• Build vs. buy on AT Protocol auth. The hard, error-prone parts — DPoP proof generation and nonce handling, PAR, handle→DID→PDS→authorization-server resolution with the bidirectional handle check, and client_uri-vs-client_id origin validation — are already implemented and were exercised against bsky.social in production on WecoPost. The realistic alternative is 3–6 weeks of engineering plus ongoing spec-churn maintenance.
• Roadmap: cross-posting / social publishing. AtprotoClient gives authenticated XRPC get, post, and uploadBlob with automatic token refresh. That directly unblocks "publish to Bluesky" and image-attachment features, which are the usual first two asks once social distribution is on the roadmap.
• Session lifecycle as a product concern, already solved. SessionManager refreshes before expiry and serializes with symfony/lock (important for multi-worker/queue deployments — concurrent refreshes are a classic production incident), and supports revocation. This supports decisions like "can we offer disconnect/revoke account?" without bespoke work.
• Infrastructure commitments surfaced early. The package ships client metadata and JWKS endpoints plus an atproto-oauth:generate-key command, which means adopting it implies hosting a stable public HTTPS client_id/metadata URL and managing an ES256 private key. That's an ops/security line item to price before committing.
• Framework scope decision. This is a Symfony bundle (Symfony 7.2+/8.x, PHP 8.2+), not a Laravel package. For a Laravel codebase the decision is explicitly "adopt with a thin adapter" (service provider, config wiring, routes for metadata/JWKS, symfony/lock cache store) rather than "install and go."

When to Consider This Package

Adopt / evaluate when:

• You are on PHP 8.2+ and Symfony 7.2+ or 8.x, or you are on Laravel and willing to own a small integration layer for a Symfony bundle (Laravel already runs on Symfony components, so symfony/lock, HTTP client, and routing are compatible — the container/config glue is the work).
• You need confidential-client OAuth against an atproto authorization server, i.e. server-side app with a secret key and a hosted client_id URL.
• You need write actions or identity-linked reads (post, uploadBlob, session refresh/revoke) — not just public read-only timeline fetches, which don't require this flow.
• You value getting a production-tested-but-young implementation over waiting for a 1.0 with a support contract.

Look elsewhere / defer when:

• You need a Laravel-native package with a published service provider, config file, and facade — you'd be building and maintaining that adapter yourself.
• You need a public/native/mobile client flow; this release is explicitly confidential-client only.
• You only need read-only public data — no OAuth, no keys, no hosted endpoints required.
• You require semantic-versioning stability, an SLA, or a security review of a mature codebase. v0.1.0 means APIs can move; treat it as a pinned dependency behind your own interface.
• Your environment can't host a stable public HTTPS metadata/JWKS endpoint (strict local-dev-only, or multi-tenant per-domain clients where client_id origin matching gets complicated).
• The atproto OAuth spec is still evolving; if you cannot absorb upstream churn, wait for a 1.0 or wrap it thinly.

How to Pitch It (Stakeholders)

Executives: This is a small, first-release library that lets us add "Sign in with Bluesky" and publish-to-Bluesky without building AT Protocol's authentication machinery ourselves. It was already run against bsky.social in production on another product, so the risky cryptography (DPoP, PAR, signed client assertions) is proven rather than theoretical. The cost is low and the payoff is a credible decentralized-social story and a new distribution channel. The caveat is maturity: it's v0.1.0, single-reference, no support contract — I recommend a two-week timeboxed spike behind a feature flag, not a bet-the-roadmap commitment.

Engineering: You get the full confidential-client flow, handle/DID/PDS/auth-server resolution with bidirectional handle verification, DPoP nonces, pre-expiry refresh serialized via symfony/lock, revocation, and an XRPC client with automatic refresh. What you don't get: a Laravel service provider, key rotation tooling, or caching for identity resolution. Budget for (1) an adapter layer — we should define our own interface and keep the bundle as an implementation detail so a v0.2 breaking change is a one-file fix, (2) hosting and monitoring the client_id metadata + JWKS endpoints, (3) secure private-key storage and a rotation runbook, (4) caching for DID/handle/PDS lookups since discovery is network-bound. Pin the version exactly; no caret ranges on a 0.x dependency.

Bottom line: worth a scoped pilot now; gate GA on a key-management story, a Laravel adapter, and a stability read on the next one or two releases.