Runet Id Bundle Laravel Package

Technical Evaluation

Architecture fit. Despite being catalogued as a Laravel/PHP package, ruwork/runet-id-bundle is a Symfony bundle, not a Laravel package. It targets the Symfony Security component and DI container, exposing a runet_id firewall/authenticator and an API client for the RUNET-ID identity provider (the Russian national digital identity service operated in the .RU/.РФ ecosystem). It has no Laravel service provider, guard, or Socialite driver, so it does not fit a Laravel application's auth stack without a port. Treat it as a reference implementation and API client, not a drop-in dependency.

Integration feasibility. Feasible only as a source-extraction exercise. The realistic path is to fork or vendor the RUNET-ID OAuth2/identity flow (HTTP client, DTOs, token handling) and reimplement the framework-facing layer as a Laravel Socialite provider or a custom guard. Installing it directly is not viable: pinned to 2018-era constraints (likely PHP 7.x, Symfony 3.4/4.0), it will conflict with modern Laravel (PHP 8.1+) on composer require, and its dependency tree pulls Symfony components Laravel either doesn't use or uses differently.

Technical risk. High.

• Abandoned upstream. Last release 2018-08-20, archived repository, 0 stars, 0 dependents, no issue triage. There is no maintainer, no security response path, and no evidence of production usage.
• Security surface. Identity and token-handling code that has had no audit or patch activity for ~7 years should be treated as untrusted until reviewed.
• API drift. The RUNET-ID API contract may have changed since 2018; endpoint, scope, and claims compatibility are unverified.
• Maintenance liability. Any adoption is a permanent fork commitment for the team.
• Mitigating factor. MIT license permits forking, and the bundle is likely small enough to audit fully; the underlying OAuth2 flow is standard and reimplementable.

Key questions.

1. Is RUNET-ID a genuine product requirement (Russian user acquisition, .RU domain registration, partner portal), or an inherited nice-to-have?
2. Does the RUNET-ID API still match the 2018 contract, and can we obtain current documentation and sandbox credentials?
3. Do we have Laravel-native alternatives (custom Socialite provider, direct OAuth2 client) that avoid carrying Symfony code?
4. What is the data-residency/PII posture (Russian 152-ФЗ) for storing RUNET-ID profile data?
5. Is there a maintained successor package or an official vendor SDK?

Integration Approach

Stack fit. Poor as-is, acceptable as a source reference. The bundle's value is the RUNET-ID-specific logic (endpoints, scopes, claim mapping, error codes), not its Symfony integration. That logic is framework-agnostic and portable.

Migration path.

• Recommended: Do not add the package to composer.json. Clone the repo, audit the API client and DTOs, and port them into a first-party Laravel integration (Socialite provider preferred; custom guard if RUNET-ID session semantics differ from standard OAuth2).
• Fallback: Fork the repo into an internal namespace, update composer.json platform constraints, replace Symfony-coupled layers with Laravel equivalents, and vendor only the API client.
• Not recommended: --ignore-platform-reqs installs or bridging Symfony Security into Laravel — brittle, hard to test, and hard to hand over.

Compatibility. Verify PHP version floor, PSR/HTTP client choice (Guzzle/HTTPlug), and Symfony component major versions before estimating effort. Expect to rewrite the authenticator, user provider, and DI wiring; retain the transport and DTO layer with light edits.

Sequencing.

1. Discovery (1–2 days): read source, map the RUNET-ID flow, confirm API currency against current docs and sandbox.
2. Spike (2–3 days): stand up a Laravel Socialite provider against RUNET-ID sandbox credentials; validate scopes, token refresh, and profile claims.
3. Build (1–2 weeks): implement provider/guard, user mapping, error handling, and tests.
4. Rollout: feature-flag behind a config toggle, ship to an internal cohort, then general availability.

Operational Impact

Maintenance. Zero upstream support; we own the code indefinitely. Budget a recurring line item for dependency updates and API-drift checks, and assign a named owner. Pin the ported code with tests so it survives Laravel upgrades.

Support. No maintainer, no documentation beyond the source, no community. Internal runbooks and an on-call contact are mandatory before launch.

Scaling. Identity flows are low-QPS relative to core traffic; the bundle itself is not a scaling bottleneck. The real decisions are token/session storage (cache vs. database) and callback endpoint resilience — both our design choices, not the package's.

Failure modes.

• RUNET-ID API outage or latency → login blocked; needs graceful degradation and clear error UX.
• Token expiry/refresh bugs → silent session loss.
• Claim-schema drift → user-mapping failures on login.
• Callback replay / CSRF / state-parameter handling → security exposure if the ported code is not reviewed.
• Unmaintained crypto or HTTP dependencies → CVE exposure over time.

Ramp-up. Low for a PHP/Symfony-literate engineer (small codebase, standard OAuth2), higher for a Laravel-only team. Allocate 2–3 days of reading and a half-day knowledge transfer; document the ported flow and the RUNET-ID contract as part of the deliverable so the integration is not tribal knowledge.

TPM recommendation. Do not adopt the package as a dependency. Treat it as an archived reference, extract and reimplement the RUNET-ID-specific logic in a first-party Laravel integration, and gate the decision on confirming the API is still current and that RUNET-ID is a validated product requirement.