Weave Code
Auth Laravel Package
orchestra/auth
Orchestra Auth is an authentication extension for the Orchestra Platform, built on Laravel's native auth system. It provides user login, registration, password management, and access control scaffolding to secure your Orchestra-powered applications.
Orchestra/Auth provides authentication support for the Orchestra Platform, extending Laravel’s native auth system with ready-to-use scaffolding for login, registration, and password management. It integrates cleanly with Orchestra’s application structure, letting developers add secure user authentication without rebuilding common flows.
- Drop-in login, registration, and logout handling
- Password reset and reminder workflows
- Configurable auth routes, controllers, and views
- Seamless integration with the Orchestra Platform
- Extensible foundation for custom user providers and guards
Frequently asked questions about Auth
- What is orchestra/auth and when should I use it instead of Laravel's built-in auth?
- orchestra/auth is the authentication component of the Orchestra Platform, built on top of Laravel's native guards and providers rather than replacing them. It ships login, registration, logout, and password reset and reminder flows along with configurable routes, controllers, and views, so you do not rebuild those screens from scratch. It is worth adopting when you are already building on Orchestra and want the platform's sanctioned layer for users, roles, and ACL. Outside Orchestra it mostly reduces to a thin wrapper over Laravel auth plus a set of shipped migrations and models.
- How do I install orchestra/auth in a Laravel application?
- Install it with composer require orchestra/auth; the service provider is auto-discovered. Publish the package configuration and migrations, then run php artisan migrate. Point the guards and providers in config/auth.php at the Orchestra user model so the eloquent provider resolves correctly. Check the package's composer.json on Packagist for the exact Laravel and PHP constraints before you commit to it.
- Does orchestra/auth work outside the Orchestra Platform?
- It still runs on Laravel, but the value proposition collapses: it becomes a thin wrapper over Laravel's native auth plus shipped migrations and models. You then inherit Orchestra conventions and the platform dependency without the platform that justifies them. For applications that are not on Orchestra, Laravel's own auth scaffolding or a mainstream package is the better fit.
- Is orchestra/auth a replacement for Laravel Breeze, Jetstream, or Fortify?
- Not in the usual sense: it is not a UI starter kit like Breeze or Jetstream, and it is not a standalone feature library like Fortify. It is the Orchestra-native layer that extends Laravel's guards and providers with Orchestra-aware behavior. Running it alongside a mainstream RBAC package would give you two competing auth paradigms, which is a net negative. Choose it because you are an Orchestra shop, not because it substitutes for those packages.
- Which Laravel and PHP versions does orchestra/auth support?
- Package versions track Orchestra Platform majors, so an Orchestra upgrade generally forces an auth major upgrade. The precise Laravel and PHP matrix is not clearly documented in the overview, so verify the constraints in the package's composer.json on Packagist. Confirm explicitly whether it hard-depends on Orchestra core. Treat the supported matrix as a question to answer before commitment rather than an assumption.
- How do I configure guards, providers, and the user model for orchestra/auth?
- The main integration seam is config/auth.php, where you define the guards and providers and point the eloquent provider at the Orchestra user model. From there, publish the package config to set table names and auth route, controller, and view options, then rebuild your config cache. Call sites stay idiomatic, so auth()->user(), @auth, and the auth middleware all work as usual and existing Laravel knowledge transfers. The shipped routes, controllers, and views can be overridden for custom flows.
- Does orchestra/auth deviate from Laravel's default password reset, email verification, or remember-me behavior?
- The package documents that it integrates with Laravel's native auth services, but documented integration is not the same as documented non-deviation in password resets, email verification, remember-me, and session invalidation. Those paths are exactly where a wrapper can diverge quietly. There is very little external evidence to lean on, since the package has no third-party dependents and a low Packagist score. Verifying these behaviors is a test task, not a documentation task.
- Why are my .env changes to auth guards or table names ignored after running config:cache?
- Config caching serializes your configuration, so later .env changes to guards, providers, or table names are silently ignored until the cache is rebuilt. Any change to auth-related environment values needs php artisan config:clear or a fresh config:cache run. Bake that into your deployment runbook, because silent auth misconfiguration in production is hard to spot.
- How do I test login, registration, and password reset flows built with orchestra/auth?
- Test the flows you actually rely on, including login, registration, logout, password reset, remember-me, and session invalidation, against your configured guards and user model rather than only the happy path. Run the suite in CI, because v5.0.1 fixed a config() to Config facade issue that surfaced only from a testing environment. Watch foreign-key ordering if you add custom tables around the auth schema, since it can break migrate:rollback. If anyone forked or copied the package migrations into the app, those local copies still carry the pre-5.0.1 behavior and the Composer pin will not fix them.
- Is orchestra/auth actively maintained, and how do Orchestra major releases affect upgrades?
- Maintenance is tied to the Orchestra Platform: releases follow Orchestra majors, so an auth upgrade is never a routine composer update and needs its own allocation. There are no third-party dependents or public upgrade write-ups to lean on, so plan to own the internals yourself. Decide and write down an explicit support model and a named owner for the auth dependency. Pin ^5.0.1, add a rollback CI job, and treat each Orchestra major as a scheduled migration rather than an incidental bump.
Weaver
How can I help you explore Laravel packages today?