Auth Yandex Laravel Package

Technical Evaluation

Architecture fit. baks-dev/auth-yandex is a Symfony bundle, not a Laravel package. It ships bin/console commands (baks:assets:install), Doctrine migrations (doctrine:migrations:diff|migrate), and depends on baks-dev/core:^7.4 plus PHP 8.4+. There is no ServiceProvider, no config/auth.php guard/driver, no Artisan command, no Blade views. In a Laravel codebase, composer require succeeding is not evidence that anything executes. Architecturally the package is one thing: a Yandex ID OAuth 2.0 flow (~150 lines of real logic) plus a Doctrine identity table, wrapped in Symfony conventions.

Integration feasibility. Two honest paths:

For a typical Laravel shop, the package's value is as a specification: it pins the endpoints (oauth.yandex.ru/authorize, /token, login.yandex.ru/info), the scope set, the format=json parameter, and the identity schema. That is a real, if modest, saving — it de-risks protocol details that are otherwise guessed from Yandex docs.

Technical risk.

• Bus factor 1 / zero validation. 0 stars, 0 dependents, MIT, README-only documentation, changelogs that read v7.4.5 — v7.4.5. No community, no CVE history, no third-party usage to learn from. Treat it as vendor-adjacent code you will own.
• PHP 8.4 hard floor. Laravel 10/11 estates commonly sit on 8.2/8.3. Composer will resolve to nothing or an older tag; verify with composer why baks-dev/auth-yandex before planning. Do not discover this in staging.
• Release metadata anomaly. Latest release is dated 2026-05-07 — a future date relative to normal review cadence. Either a mislabeled tag, a timezone artifact, or a repository whose versioning isn't tied to real chronology. Flag in diligence; it undermines confidence in release discipline and makes "last release" useless as a maintenance signal.
• Doctrine ≠ Eloquent. Migration SQL must be hand-translated. Doctrine string → 255, datetime vs timestamp, differing unique-index naming. A missed unique index on the Yandex identifier produces duplicate-user bugs that only surface under concurrent registration.
• Silent no-op failure mode. baks:assets:install on a Laravel app will either error or quietly do nothing, because there is no asset pipeline to publish into. Commands that fail loudly are fine; commands that succeed and do nothing are how teams ship broken auth.
• Email-based linking is an account-takeover vector if the package (or your bridge) links a Yandex identity to an existing local account without confirmation.

Key questions to resolve before committing.

1. Does the bundle read YANDEX_CLIENT_ID / YANDEX_CLIENT_SECRET from $_ENV directly, or from a Symfony param bag requiring config/packages/*.yaml? Grep vendor/ — the README does not say.
2. What is the exact registered route and redirect URI (trailing slash, locale prefix, /callback suffix)? Yandex is byte-strict; mismatches surface as an undetailed invalid_request.
3. Which scopes does it request (login:email, login:info)? Are they minimal for our use case?
4. What does baks-dev/core:^7.4 impose — does it expect its own user entity, base tables, or an existing Baks schema? This determines whether the migrations are additive or parasitic.
5. Does it persist access/refresh tokens, and where? Server-side storage or session?
6. Who maintains this, and is there any release cadence behind the 7.4.x line?
7. How does it behave under a locale-prefixed URL (/ru/auth/yandex)? Redirect URI drift is the top production failure.

Integration Approach

Stack fit. In Laravel, keep Laravel as front controller and treat the package as protocol documentation. One thin controller owns redirect + callback; the package's flow is re-expressed in Laravel idioms (Http::asForm(), Auth::login()). In Symfony on baks-dev/core, install it properly: composer require, Yandex app registration, .env keys, baks:assets:install, doctrine:migrations:diff → review the SQL → migrate.

Migration path (Laravel).

1. composer require baks-dev/auth-yandex in a throwaway branch purely to read vendor/ — src/Controller, src/Security, OAuth client, Migrations/. Uninstall afterwards if PHP 8.4 blocks it; clone the repo instead.
2. Register the Yandex app (Бизнес → Яндекс ID для сайта) and set the redirect to https://<DOMAIN>/auth/yandex. Do this early — app review is a lead-time item outside engineering's control.
3. Translate the identity schema to an Eloquent migration: a yandex_identities pivot (user_id FK, yandex_id unique, nullable email, email_verified, timestamps). Do not add columns to users.
4. Implement redirect/callback with state stored in session, validated via hash_equals on a session()->pull() value.
5. Link-on-yandex_id first; on email collision with an existing local account, require explicit confirmation rather than silent linking.
6. Store tokens server-side (cache keyed by user + provider), never in cookies or view data.
7. Feature-test the whole flow with Http::fake() — happy path, bad state, error=access_denied, email-already-taken, second login for a known yandex_id (no duplicate row).

Compatibility. Gate on PHP 8.4 first; it is the single most likely blocker and it is binary. If you reimplement, you need neither Doctrine nor baks-dev/core — only the HTTP contract. If you adopt, confirm your Symfony version and baks-dev/core constraint align before sequencing anything else.

Sequencing. (1) Vendor read spike, 1 day. (2) Decision: adopt vs reimplement — make it explicitly, in writing. (3) Yandex app registration, parallel track, longest lead time. (4) Schema. (5) Redirect/callback behind a feature flag. (6) Linking policy + security review. (7) Token storage. (8) Tests. (9) Staged rollout. Do not start with roles, account unlinking, or refresh-token rotation.

Operational Impact

Maintenance. Assume you own the code regardless of path. Zero dependents and zero stars mean no downstream pressure to fix breakage; upstream churn is unpredictable and undocumentable. Pin an exact version, vendor the source if adopting, and budget a quarterly review of the Yandex OAuth contract (scopes, endpoint hostnames) — providers do deprecate.

Support. Effectively none. Documentation is a Russian-language README covering install and env only; the only real spec is the --group=auth-yandex test suite. There is no SLA, no maintainer responsiveness signal, and no community to search. Any incident is an internal incident. Plan for a named owner on the team, not "whoever touched auth last."

Scaling. The OAuth flow itself is not a scaling concern — it is a low-volume, per-login handshake. Watch three things: (a) server-side token storage growth and expiry cleanup; (b) session-backed state under multi-instance deployments (shared session store required, or sticky/stateless handling); (c) Yandex API rate limits and latency on /token and /info during login spikes — the callback is now on the critical path of your login funnel and a Yandex slowdown is your outage. Add a timeout and a graceful "try another sign-in method" fallback.

Failure modes to instrument.

Ramp-up. Roughly 1 day to read and understand the vendor tree, 2–4 days to build and test a Laravel bridge, plus Yandex app approval lead time (outside your control — start it on day one). Required skills: OAuth 2.0 fundamentals, Laravel HTTP client and testing, and one security review pass focused on state validation and account linking. Total TPM-level estimate: one engineer, one sprint, most of it spent on the linking policy and tests rather than the protocol.

Bottom line. The package is a small, single-purpose Symfony bundle with no ecosystem validation and a future-dated release. In a Symfony-on-baks-dev/core stack it is a reasonable low-effort add. Everywhere else it is a reference implementation worth one day of reading and not a dependency worth owning — the Yandex OAuth flow is small enough that reimplementing it in your own framework yields better long-term supportability, clearer security semantics around account linking, and no PHP 8.4 upgrade coupling.