Authentication guards in Laravel - Step-by-Step Execution

Concept Flow - Authentication guards

User sends request

↓

Guard checks if user is logged in

↓

Yes

↓

Allow access

↓

Controller handles request

The guard checks if the user is authenticated before allowing access or redirecting to login.

Execution Sample

Laravel

<?php
// In routes/web.php
Route::get('/dashboard', function () {
    return 'Welcome to dashboard';
})->middleware('auth');

This route uses the auth guard to allow only logged-in users to access the dashboard.

Execution Table

Step	Request URL	Guard Check	User Authenticated?	Action Taken	Response
1	/dashboard	Check auth guard	No	Redirect to /login	Redirect response
2	/login	No guard needed	N/A	Show login form	Login form HTML
3	User submits login form	Validate credentials	Yes	Set user session	Redirect to /dashboard
4	/dashboard	Check auth guard	Yes	Allow access	Show dashboard content

💡 Execution stops when user is either redirected to login or allowed access to dashboard.

Variable Tracker

Variable	Start	After Step 1	After Step 3	After Step 4
user_authenticated	false	false	true	true
response	none	redirect to /login	redirect to /dashboard	dashboard content

Key Moments - 2 Insights

Why does the user get redirected to /login at first?

Because the guard check at Step 1 finds the user is not authenticated (see execution_table row 1). Guards block access if not logged in.

What happens after the user logs in successfully?

At Step 3, credentials are validated and user_authenticated becomes true (see variable_tracker). Then user is redirected to /dashboard.

Visual Quiz - 3 Questions

Look at the execution_table, what is the response at Step 1?

A Show dashboard content

B Redirect to /login

C Show login form

D Redirect to /dashboard

💡 Hint

Check the 'Response' column in execution_table row 1.

At which step does user_authenticated change from false to true?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look at variable_tracker row for user_authenticated.

If the guard was removed from the /dashboard route, what would happen at Step 1?

A User would see dashboard content even if not logged in

B User would be redirected to /login

C User would see login form

D User session would be cleared

💡 Hint

Without guard, no authentication check blocks access (see concept_flow).

Concept Snapshot

Authentication guards check if a user is logged in before allowing access.
If not authenticated, user is redirected to login page.
Use middleware('auth') on routes to apply guard.
After login, guard allows access to protected routes.
Guards help protect pages from unauthorized users.

Full Transcript

Authentication guards in Laravel act like gatekeepers. When a user requests a page, the guard checks if they are logged in. If not, it sends them to the login page. Once logged in, the guard lets them access protected pages like the dashboard. This is done by adding the 'auth' middleware to routes. The execution flow starts with a request, guard check, possible redirect, and finally the controller response. Variables like user_authenticated track login state. Guards keep your app secure by blocking unauthorized access.

Practice

1. What is the main purpose of an authentication guard in Laravel?

easy

A. To manage session timeouts

B. To store user passwords securely

C. To define database connections

D. To control how users are authenticated for each request

Solution

1. Step 1: Understand the role of authentication guards

   Guards determine how users are authenticated on each request, like checking credentials or tokens.

2. Step 2: Differentiate guards from other features

   Guards do not store passwords, manage sessions, or define databases; those are handled elsewhere.

3. Final Answer:

   To control how users are authenticated for each request -> Option D

4. Quick Check:

   Authentication guard = controls user authentication [OK]

Hint: Guards decide how users log in and access app [OK]

Common Mistakes:

• Confusing guards with password storage
• Thinking guards manage database connections
• Assuming guards handle session timeouts

2. Which of the following is the correct way to specify a guard in Laravel's auth.php config file?

easy

A. 'guards' => ['web' => ['driver' => 'database', 'provider' => 'users']]

B. 'guards' => ['web' => ['driver' => 'token', 'provider' => 'admins']]

C. 'guards' => ['web' => ['driver' => 'session', 'provider' => 'users']]

D. 'guards' => ['api' => ['driver' => 'session', 'provider' => 'users']]

Solution

1. Step 1: Check the standard guard configuration

   Laravel's default 'web' guard uses 'session' driver and 'users' provider.

2. Step 2: Validate driver and provider correctness

   'database' is not a valid driver for guards; 'token' is used for API guards, but 'web' uses 'session'.

3. Final Answer:

   'guards' => ['web' => ['driver' => 'session', 'provider' => 'users']] -> Option C

4. Quick Check:

   Default web guard uses session driver [OK]

Hint: Web guard uses session driver and users provider [OK]

Common Mistakes:

• Using 'database' as a driver instead of 'session'
• Mixing 'token' driver with 'web' guard
• Assigning wrong provider names

3. Given this code snippet in a Laravel controller:

if (Auth::guard('admin')->check()) {
    return 'Admin logged in';
} else {
    return 'No admin logged in';
}

What will be the output if no admin user is logged in but a regular user is?

medium

A. No admin logged in

B. Error: guard not found

C. Admin logged in

D. No output

Solution

1. Step 1: Understand what Auth::guard('admin')->check() does

   This checks if a user is logged in using the 'admin' guard specifically.

2. Step 2: Analyze the scenario

   No admin user is logged in, so check() returns false, even if a regular user is logged in under a different guard.

3. Final Answer:

   No admin logged in -> Option A

4. Quick Check:

   Guard check false means no user logged in for that guard [OK]

Hint: Guard check only sees users of that guard [OK]

Common Mistakes:

• Assuming any logged-in user passes the guard check
• Confusing guard names
• Expecting error if guard exists

4. Identify the error in this Laravel guard usage:

Auth::guard('web')->login($user);
if (Auth::check()) {
    return 'User logged in';
}

medium

A. No error, code works correctly

B. Auth::check() does not check the 'web' guard by default

C. Missing middleware to protect the route

D. Auth::guard('web')->login() requires a user ID, not a user object

Solution

1. Step 1: Understand Auth::guard('web')->login()

   This logs in the user using the 'web' guard explicitly.

2. Step 2: Check what Auth::check() does

   Auth::check() uses the default guard, which may not be 'web', so it might not detect the login.

3. Final Answer:

   Auth::check() does not check the 'web' guard by default -> Option B

4. Quick Check:

   Auth::check() uses default guard, not necessarily 'web' [OK]

Hint: Auth::check() uses default guard, not specified guard [OK]

Common Mistakes:

• Assuming Auth::check() checks all guards
• Thinking login() needs user ID only
• Ignoring middleware importance

5. You want to protect an admin route so only users authenticated with the 'admin' guard can access it. Which is the correct way to apply this in Laravel's route definition?

hard

A. Route::middleware('auth:admin')->group(function () { Route::get('/admin', fn() => 'Admin area'); });

B. Route::middleware('auth:web')->group(function () { Route::get('/admin', fn() => 'Admin area'); });

C. Route::middleware('guest:admin')->group(function () { Route::get('/admin', fn() => 'Admin area'); });

D. Route::middleware('auth')->group(function () { Route::get('/admin', fn() => 'Admin area'); });

Solution

1. Step 1: Understand middleware usage for guards

   The 'auth' middleware accepts a guard name to specify which guard to check for authentication.

2. Step 2: Choose the middleware that checks 'admin' guard

   'auth:admin' ensures only users authenticated with 'admin' guard access the route.

3. Step 3: Eliminate incorrect options

   'auth:web' checks the wrong guard, 'guest:admin' checks for unauthenticated users, and 'auth' without guard uses default guard.

4. Final Answer:

   Route::middleware('auth:admin')->group(function () { Route::get('/admin', fn() => 'Admin area'); }); -> Option A

5. Quick Check:

   Use 'auth:guardname' middleware to protect routes [OK]

Hint: Use 'auth:admin' middleware to protect admin routes [OK]

Common Mistakes:

• Using 'auth' without specifying guard
• Using 'guest' middleware instead of 'auth'
• Applying wrong guard name in middleware