Auth Yandex Laravel Package

Product Decisions This Supports

• Feature scoping for CIS-market onboarding. Yandex ID is a top-5 identity provider in Russia/CIS; this package is a ready-made proof point that "login with Yandex" is a ~1–3 day feature, not a multi-sprint epic. That materially changes how you size and sequence the auth roadmap item for any product targeting that region.
• Build vs. buy triage. The package is MIT and tiny, but it is a Symfony bundle, not a Laravel package — no ServiceProvider, no config/auth.php driver, no Artisan commands, and it pins PHP 8.4+. So the real decision is rarely "adopt this" but "use this as the reference implementation for a ~150-line in-house OAuth2 flow, or stand up a Symfony kernel alongside Laravel." Either way, the PM decision is buy the knowledge, build the integration — a small, bounded, low-risk build.
• Prioritization signal against alternatives. Zero stars, zero dependents, and stub release notes ("v7.4.6 — v7.4.6") tell you there is no community, no SLA, and no support surface. It competes not with Socialite but with "do nothing." The PM decision this informs: whether Yandex login is a must-have for the target segment or a nice-to-have that can wait for a maintained alternative (e.g. Laravel Socialite + a Yandex provider) rather than an unmaintained single-purpose bundle.
• Roadmap dependency mapping. Adoption drags in Doctrine migrations, a Symfony console, and the baks-dev/core user entity — non-trivial architectural coupling for a Laravel app. That is a roadmap cost to surface early: this is not a drop-in; it's a pattern to port.
• Risk register entry. The account-linking behaviour (keying on yandex_id, not email, and requiring confirmation before linking an existing local account) is a security product decision, not just an engineering detail. The PM owns the call on "silent link vs. confirm," because getting it wrong is an account-takeover vector.
• Localisation/growth experiments. Yandex login is often a conversion lever for Russian-speaking users. This package makes it cheap enough to A/B test the login screen without committing to a platform-wide auth refactor.

When to Consider This Package

Consider it when:

• Your product targets Russia/CIS and Yandex ID is a meaningful share of your target users' login preference.
• You are already on a Symfony stack (or run Symfony components) — then the bundle genuinely is close to drop-in, and the baks:assets:install / Doctrine migration flow works as documented.
• You want a reference implementation of the Yandex OAuth2 flow (authorize → token exchange → login.yandex.ru/info) to port into Laravel — the README plus source is a decent spec, and the auth-yandex PHPUnit group gives you behavioural hints.
• You are on PHP 8.4+ and comfortable translating Doctrine schema to Eloquent migrations by hand.
• You need a narrow, single-provider login and are willing to own the maintenance yourself (MIT, so you can fork freely).

Look elsewhere when:

• You want composer require and done in Laravel. It will not happen. Use Laravel Socialite with a Yandex driver, or write the ~150-line controller — both are lower total cost than bridging this.
• You are on PHP 8.2/8.3 (typical for Laravel 10/11). The php 8.4+ constraint is a hard blocker; don't discover it in staging.
• You need multi-provider auth (Google, VK, GitHub, etc.). This package is Yandex-only; Socialite is the strategic choice.
• You need active maintenance, security advisories, or community support. Zero stars, zero dependents, and content-free release notes are the signal.
• You cannot match the redirect URI exactly or operate a real TLS host in dev — Yandex surfaces mismatches as an opaque invalid_request.

How to Pitch It (Stakeholders)

To executives: "Yandex ID login is a one-to-three-day feature if we treat this package as a reference implementation rather than a dependency. It's an MIT-licensed, single-purpose module for Yandex OAuth2 login — small, readable, no lock-in. The catch: it's built for Symfony, and our stack is Laravel, so we won't composer require it — we'll use its flow as the spec and implement it natively in about 150 lines with Laravel Socialite-style code. The strategic value is speed-to-market for CIS users at near-zero licensing cost and near-zero vendor risk. The real decisions for you are (1) is Yandex login a must-have for our target segment this quarter, and (2) do we accept a small bespoke auth surface we own forever versus waiting for a maintained Socialite driver."

To engineering: "This is a Symfony bundle with Doctrine migrations and a bin/console install step — none of which runs in our Laravel app, and it hard-requires PHP 8.4. Recommendation: port, don't install. Read vendor/baks-dev/auth-yandex/src/ for the exact endpoints and scopes, translate the Doctrine migration to an Eloquent yandex_identities pivot table keyed on yandex_id (never email), validate state with hash_equals, and keep tokens server-side in cache — never in session or Blade. Feature-test the whole flow with Http::fake() covering: valid callback, bad state, access_denied, email collision with an existing local account (must require confirmation — this is an account-takeover vector, not a UX nicety), and repeat login for a known yandex_id (must not duplicate the user). Budget half a day just reading the vendor source before writing code; the README covers install and env only. Treat this as a small, well-bounded build we fully control."