Oauth Server Bundle Laravel Package

Product Decisions This Supports

• Legacy-compatibility scoping. If a customer, partner, or regulator requires an OAuth 1.0 (RFC 5849) server endpoint — common in education (LTI 1.1), older B2B APIs, and a handful of legacy SaaS integrations — this codebase gives you a concrete, spec-aligned baseline for what "done" looks like: request-token → authorize → access-token flow, HMAC-SHA1/PLAINTEXT/RSA-SHA1 signature verification, nonce/timestamp replay defense, and token credential storage.
• Build vs. buy vs. gateway. There is no maintained, drop-in OAuth 1.0 server library in the PHP ecosystem (the well-known packages are client-side or OAuth 2.0). Reading this repo lets you price the internal build or justify terminating OAuth 1.0 at an API gateway instead of in application code.
• Tech-debt inventory and migration roadmap. Because the bundle is Symfony2-era and archived, any internal service still depending on it is a flagged risk item. This supports a decision to schedule migration to OAuth 2.0/2.1 + OIDC rather than extend the legacy path.
• Protocol conformance review. Useful as a readable reference when auditing a partner's OAuth 1.0 implementation (signature base string construction, percent-encoding rules, parameter normalization) — a frequent source of integration bugs.
• Roadmap positioning. Confirms OAuth 1.0 server support is a "keep-the-lights-on" compatibility capability, not a growth surface. Product investment should be timeboxed and isolated behind an interface with a defined exit.

When to Consider This Package

Consider (narrowly):

• You are maintaining an existing Symfony 2.x application and need to preserve behavior during a migration window.
• You must expose OAuth 1.0 server endpoints and accept full ownership: vendoring/forking, security patching, and contract tests — you are treating it as source material, not a dependency.
• You want a compact, RFC-referenced teaching example to bootstrap an in-house implementation.

Look elsewhere (default):

• Any new build. OAuth 1.0 is superseded; use OAuth 2.0/2.1 with OIDC (league/oauth2-server, Laravel Passport, or a managed IdP).
• You need maintenance, security response, or compliance evidence. The repo is archived with 31 stars and zero dependents — it will fail procurement and vulnerability-review gates, and OAuth server code is security-critical.
• You're on Laravel. This is a Symfony bundle; the DI wiring, controllers, and event hooks don't transfer. You'd be reimplementing the useful parts anyway, which erodes the "buy" case entirely.
• Only client-side OAuth 1.0 is needed — use league/oauth1-client or a Guzzle subscriber instead.
• You only need API tokens — Laravel Sanctum or simple bearer tokens are cheaper and safer than a full OAuth 1.0 server.
• Modern PHP/Symfony versions — the code targets Symfony2 APIs that no longer exist; porting cost likely exceeds a clean implementation.

How to Pitch It (Stakeholders)

Executives: This is not a package we adopt. It's a 31-star, archived Symfony2 library implementing a protocol (OAuth 1.0) that the industry moved off of years ago. Its value to us is as a scoping and conformance reference, not a shipping component. Recommendation: do not add it to the stack. If a customer contractually requires OAuth 1.0 server support, treat that as a bounded legacy-compatibility workstream — ideally terminated at the API gateway — with a named owner and a migration path to OAuth 2.0/OpenID Connect. Budget it as maintenance, not roadmap.

Engineering: Use it as a reading reference for RFC 5849 edge cases (signature base string, encoding, nonce handling). Do not vendor it as-is. If a legacy requirement forces adoption, fork and pin it, wrap it behind our own interface, add conformance and replay-protection tests, and document the exit criteria up front — assume we own all future security fixes.