Laravel 5 new auth: Get current user and how to implement roles?
Stefan Bogdanescu
Founder & Senior Architect · 2026-06-29
# Laravel 5 Auth Deep Dive: Getting the User and Implementing Roles
As developers move through different versions of a framework like Laravel, understanding not just *how* things work, but *how they should work*, is crucial. When you start with the foundational authentication system in Laravel 5—registering users and handling login sessions—you naturally encounter the next big hurdle: authorization. This post addresses how to correctly access the authenticated user data and, more importantly, how to implement robust role and permission management within your application.
## Accessing the Current User: Guard vs. Facades
You asked about injecting the `Guard` contract to retrieve the current user in your controller. While technically correct, it’s important to understand the most idiomatic Laravel way to handle this.
The `Guard` interface provides access to the underlying authentication mechanism (like session or token handling). Injecting it works, but for simple fetching of the authenticated user model, using the `Auth` facade is generally cleaner and more concise.
Here is how you can retrieve the user in your controller:
```php
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth; // Import the Auth facade
class ClientController extends Controller
{
/**
* Display a listing of the resource.
*/
public function index(Request $request)
{
// Recommended way: Use the Auth facade to get the authenticated user object
$user = Auth::user();
if (!$user) {
// Handle case where no user is logged in
abort(401, 'Unauthorized.');
}
return view('client.index', ['user' => $user]);
}
}
```
**Why this approach?** Relying on the `Auth` facade keeps your controller logic focused on *what* data you need (the user) rather than *how* the authentication mechanism works (the guard). For more complex authorization needs, Laravel provides powerful tools that abstract away the direct interaction with guards and provide cleaner methods for checking permissions.
## Implementing Roles and Permissions: The Authorization Layer
The second part of your question—implementing roles like `client.edit` or `client.add`—moves us from simple authentication (Are you logged in?) to authorization (Are you allowed to perform this action?). Laravel doesn't provide a single, built-in system for granular permissions out of the box; instead, it provides the scaffolding to build one using **Middleware**, **Gates**, and **Policies**.
### The Best Practice: Leveraging Packages
While you *could* write custom middleware to check roles on every route, this quickly becomes cumbersome. The industry standard and most efficient approach in the Laravel ecosystem is to utilize a dedicated package for role and permission management.
The most popular choice for this is the **Spatie Laravel Permission** package. This package allows you to define roles (e.g., 'Admin', 'Client') and assign specific permissions (e.g., `client.edit`, `client.add`) directly in your database.
### Step-by-Step Implementation with Spatie
1. **Installation:** Install the package via Composer:
```bash
composer require spatie/laravel-permission
```
2. **Migration:** Run the necessary migrations to create the pivot tables for roles and permissions in your database.
3. **Model Setup:** Add the `HasRoles` trait to your User model:
```php
use Spatie\Permission\Traits\HasRoles;
class User extends Authenticatable
{
use HasRoles;
// ... other traits and properties
}
```
4. **Route Protection using Middleware:** Once roles are set up, you protect your routes by applying middleware that checks if the authenticated user has the required permission. This is where you