Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Oauth Laravel Package

carlos-mg89/oauth

OAuth 2.0 package for Laravel/PHP that simplifies authorization flows, token management, and securing API routes, with configurable grants and middleware integration for adding delegated authentication to your app.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Build vs. buy for third-party integrations. This package is a candidate "buy" (adopt) option for OAuth 1/2 client work: token exchange, signing, refresh handling, and per-provider quirks. As a PM you can use it to price the alternative — roughly 2–6 engineering weeks to hand-roll OAuth 1.0a signing plus per-provider edge cases, versus a dependency you must vet. That comparison is the core of the decision.
  • Provider roadmap scoping. If your roadmap includes long-tail or legacy providers (anything still on OAuth 1.0a, or niche regional/enterprise APIs), breadth of pre-built provider classes is the actual product value here — not code quality. That lets you commit to "we support provider X" without a bespoke integration spike.
  • Legacy integration sunset planning. Teams migrating off OAuth 1 providers need a bridge while the new flow ships. This package is a plausible temporary bridge, and framing it as time-boxed rather than permanent changes the risk calculus entirely.
  • Dependency governance / vendor-risk policy. With 7 stars, 0 dependents, a composite score of ~1.29, and a NOASSERTION license, this is a useful forcing function to define adoption thresholds for your org (stars/downloads/dependents are weak proxies; license clarity and security response are not). Use it as the test case, not the exception.
  • Make-vs-fork. The realistic path for most teams isn't "depend on this" but "vendor/fork the provider classes we need into our own tree." That's a scoping decision — read-only reference (cheap) vs. maintained fork (ongoing cost) — and a PM should name which one they're buying.
  • Packaging and TCO. Adoption is not free in a Laravel codebase: no service provider, no facade, no published config, framework-agnostic by design. Budget integration and upgrade work; don't assume drop-in.

When to Consider This Package

Adopt (or fork) only when all of these hold:

  • You specifically need OAuth 1.0a or a provider that Laravel Socialite and league/oauth2-client provider packages do not cover.
  • The blast radius is small and reversible: internal tooling, an admin-side integration, or a time-boxed migration bridge.
  • You have read the code and are comfortable maintaining your own fork, with the license clarified in writing before any commercial distribution.
  • You accept no security-response guarantee and are prepared to track upstream CVEs yourself.

Look elsewhere when:

  • Greenfield Laravel + standard OAuth 2 providers (Google, GitHub, Microsoft, Slack, Okta): use laravel/socialite or league/oauth2-client with a maintained provider package. Better maintained, far larger install base, first-party Laravel ergonomics.
  • Licensing matters (commercial product, enterprise procurement, M&A diligence): NOASSERTION is a hard stop until counsel confirms terms — likely MIT inherited from the upstream project, but "likely" is not a license.
  • You need a security SLA, coordinated disclosure, or an SBOM you can defend: 0 dependents and a single maintainer mean no community backstop and no second pair of eyes.
  • You need modern flows — OIDC, PKCE-first, token rotation, DPoP: verify support explicitly; a fork of an older library may be behind on these.
  • You want low exit cost: if swapping auth libraries later would be expensive, don't start here.

How to Pitch It (Stakeholders)

For executives: This is a small, single-maintainer open-source OAuth client library that covers both OAuth 1 and OAuth 2. Its one real advantage is breadth of legacy provider support; its weaknesses are adoption (7 stars, zero downstream dependents), an unclear license, and no support or security commitments. My recommendation is not to adopt it as a platform dependency. If we have a legacy OAuth 1 integration on the roadmap, we should treat this as a short-term bridge or a source of reference code we vendor ourselves — with a defined exit date and a license review before it touches anything we ship commercially. For standard social login, we standardize on Laravel Socialite plus league/oauth2-client.

For engineering: It's a maintained fork (last release Feb 2025) of the old PHPoAuthLib, PHP 7/8, framework-agnostic — so no Laravel service provider, facade, or config publishing; integration is manual. It's actively released but effectively unvalidated by the ecosystem. If we use it, we pin the version, wrap it behind our own adapter interface so the dependency is swappable, and record the license question as an open risk. Please do not import it directly across multiple services.

Ask: approve Socialite/league as the default standard; approve a time-boxed spike on this package only if a specific OAuth 1 provider blocks a committed roadmap item — and flag the license for legal review before that spike ships.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
shitoudev/permissionmanager
johannesclimacus/laravel-tui
hocvt/seotools
vitalybaev/sypexgeo
amphibee/themosis-ignition
gito-me/fast-excel
frankyso/laravel-ipaymu
geolize-studio/laravel-chile
boomerangui/chat
jinas/dhivatar
store-doc/laravel-storage-driver
plus-it/laravel-translation-manager
diephp/perhaps
diephp/telegraph
osmaviation/spreadsheet
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console