Atproto Oauth Bundle Laravel Package

Technical Evaluation

Architecture fit: The release is a Symfony bundle, not a Laravel package — a material mismatch with the brief. It depends on Symfony's dependency-injection container, routing, console, and symfony/lock, and targets Symfony 7.2+/8.x. Laravel has no native path to boot a Symfony bundle (no service-provider auto-discovery, no config publishing, no Laravel HTTP client binding). The value on offer is the protocol logic — PAR, PKCE S256, DPoP with server nonces, ES256 private_key_jwt client assertions, DID/handle resolution — not the framework glue. For a Laravel codebase, treat this as a reference implementation to port, not a dependency to add.

Integration feasibility: The AT Protocol OAuth handshake is genuinely hard to get right (PAR, DPoP nonce negotiation and retries, bidirectional handle→DID checks, PDS/authorization-server discovery). A tested reference is worth more than the code itself. The fact it has run "in production on WecoPost" against bsky.social is meaningful signal, but n=1: one maintainer, one deployment, one PDS environment.

Technical risk:

• Framework mismatch (high): No Laravel support and no announced adapter; adopting it would require a Symfony sidecar or a ground-up port of its primitives.
• Maturity (high): v0.1.0, pre-1.0 — no compatibility guarantees; expect breaking changes.
• Test coverage breadth (medium): Only bsky.social is cited; did:web, non-bsky PDS hosts, and third-party authorization servers are unverified.
• Key management (medium): atproto-oauth:generate-key implies local key storage; no stated KMS/HSM path, rotation plan, or recovery story. Key loss invalidates all sessions.
• Runtime narrowness (low–medium): PHP 8.2+ / Symfony 7.2+ is compatible with modern Laravel runtimes but does not help bootstrap the bundle.
• Governance (medium): No stated license, security-disclosure channel, versioning policy, or maintainer continuity plan.

Key questions:

1. Is a framework-agnostic core or Laravel adapter on the roadmap, or would a port be expected?
2. What is the support/versioning policy through 1.0?
3. What is the key storage and rotation contract (file, secrets manager, KMS)?
4. Has it been exercised against did:web and non-bsky PDS implementations?
5. Is there a security review, disclosure process, and named maintainer?
6. What is the license and redistribution posture for an internal port?
7. How does the package handle DPoP nonce retries and 429/backoff from the PDS?

Integration Approach

Stack fit: Direct fit only for Symfony shops. For Laravel, the bundle itself is a non-starter; the reusable surface is the protocol logic (PAR, PKCE S256, DPoP nonce handling, ES256 client-assertion JWTs, DNS-TXT/well-known identity resolution, bidirectional handle verification, session refresh with locking).

Migration path: Two viable options.

1. Internal port (recommended): Reimplement the primitives on Laravel's HTTP client (Illuminate\Support\Facades\Http) with a DPoP nonce cache (Cache), and Cache::lock for serialized refresh. This keeps the auth flow in-process and avoids cross-service secrets.
2. Synfony sidecar: Stand up the bundle as a small auth microservice and call it from Laravel. Faster to prove out, but adds a network hop on every auth/refresh and a shared-secret or mTLS burden, plus operational surface for a second runtime.

Do not attempt to wire the Symfony bundle into Laravel's container directly; the bundle's kernel-level wiring will fight the framework.

Compatibility: PHP 8.2+ aligns with current Laravel; Symfony components can be consumed as libraries if needed, but the bundle entrypoint should be treated as unshippable in a Laravel app. Watch symfony/lock backend choice — file locks are unsafe for multi-instance deployments.

Sequencing:

1. Validate the full auth flow end-to-end against bsky.social in a throwaway Symfony sandbox to confirm behavior and edge cases (nonce retries, refresh races).
2. Prototype the Laravel port in one low-traffic app behind a feature flag; exercise login, refresh-before-expiry, revocation, uploadBlob.
3. Harden failure handling (DPoP nonce rejection, 429/backoff, key rotation).
4. Extract to a shared internal package only once a second consumer exists.
5. Roll out tiered — internal/low-risk accounts first, then broader.

Operational Impact

Maintenance: v0.1.0 implies churn. If adopting the Symfony bundle, budget for tracking a fast-moving pre-1.0 upstream. If porting, the team owns the code and must track AT Protocol spec evolution (DPoP, PAR, identity resolution are still moving targets).

Support: Single-maintainer, single-deployment provenance. No stated SLA, support channel, or LTS commitment. Escalation path is effectively upstream issues.

Scaling: OAuth flows are per-session and low-volume; not a scaling concern. Real scaling risks sit in (a) distributed locking for session refresh — symfony/lock must be Redis/DB-backed in multi-instance deploys, not file-based; (b) XRPC concurrency and PDS-side rate limits; (c) DNS/HTTPS dependency during login — identity resolution couples your sign-in availability to external DNS and well-known endpoints, so cache resolutions and degrade gracefully.

Failure modes:

• DPoP nonce rejection without a retry loop → cascading auth failures; spec requires retrying with the returned nonce.
• Key loss or rotation mishap → every session invalid, forced re-auth for all users.
• Refresh race across instances → invalidated refresh tokens and user-visible logouts.
• Identity resolution outages (DNS TXT, /.well-known/) → login unavailable even when the app is healthy.
• App-password / session revocation upstream → silent 401s if revocation isn't surfaced to the UI.
• client_uri / client_id origin drift → authorization-server rejection on client metadata.

Ramp-up: Steep. The team needs working fluency in AT Protocol OAuth, DPoP, ES256 client assertions, and DID resolution before owning either the integration or the port. Because it is Symfony-only, Laravel engineers cannot lean on framework familiarity — plan for a focused spike and a written internal runbook on the auth flow before committing to production use.