API authentication with Sanctum in Laravel - Step-by-Step Execution

Concept Flow - API authentication with Sanctum

Client sends login request

↓

Sanctum verifies credentials

↓

Sanctum issues API token

↓

Client stores token

↓

Client sends API requests with token

↓

Sanctum authenticates token

↓

Server processes request or denies access

The client logs in, Sanctum checks credentials and gives a token. The client uses this token to access protected API routes, and Sanctum verifies the token each time.

Execution Sample

Laravel

Route::post('/login', function (Request $request) {
  $user = User::where('email', $request->email)->first();
  if (! $user || ! Hash::check($request->password, $user->password)) {
    return response()->json(['message' => 'Invalid credentials'], 401);
  }
  $token = $user->createToken('api-token')->plainTextToken;
  return response()->json(['token' => $token]);
});

This code logs in a user by checking email and password, then returns a JSON response with a Sanctum API token if valid.

Execution Table

Step	Action	Input	Check/Process	Output/Result
1	Receive login request	{email: '[e-mail]', password: 'secret'}	Look up user by email	User found with matching email
2	Verify password	Password 'secret'	Compare with stored hash	Password matches
3	Create token	User object	Generate new API token	Token string generated
4	Return token	Token string	Send token in response	Client receives token
5	Client sends API request	API request with token in header	Sanctum checks token validity	Token valid, request allowed
6	Server processes request	Valid token	Execute API logic	Response data sent
7	Client sends API request	API request with invalid token	Sanctum checks token validity	Token invalid, access denied
8	Return error	Invalid token	Send 401 Unauthorized	Client receives error

💡 Execution stops when client receives token or access denied response.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	After Step 7
$request	N/A	{email:'[e-mail]', password:'secret'}	{email:'[e-mail]', password:'secret'}	{email:'[e-mail]', password:'secret'}	{email:'[e-mail]', password:'secret'}	API request with token	API request with invalid token
$user	null	User object found	User object found	User object found	User object found	User object found	User object found
$token	null	null	null	Token string generated	Token string sent	Token string sent	null
$response	null	null	null	null	JSON with token	API response data	401 Unauthorized error

Key Moments - 3 Insights

Why does Sanctum return a plain text token instead of a hashed one?

Sanctum returns a plain text token once so the client can store it. The server stores a hashed version for security. See execution_table step 3 and 4.

What happens if the password check fails?

The code returns a 401 Unauthorized response immediately, stopping token creation. See execution_sample code if condition.

How does Sanctum verify the token on API requests?

Sanctum checks the token sent in the request header against stored hashed tokens. If it matches, access is granted; otherwise, denied. See execution_table steps 5 to 8.

Visual Quiz - 3 Questions

Look at the execution table, what is the output at step 3?

A User object found

B Token string generated

C 401 Unauthorized error

D Password mismatch

💡 Hint

Check the 'Output/Result' column at step 3 in the execution_table.

At which step does Sanctum deny access due to an invalid token?

A Step 7

B Step 6

C Step 5

D Step 4

💡 Hint

Look for 'Token invalid, access denied' in the execution_table.

If the password is wrong, what will the response be?

A Token string generated

B User object found

C 401 Unauthorized error

D API response data

💡 Hint

See the code in execution_sample, step 2 verification fails.

Concept Snapshot

API Authentication with Sanctum:
- Client sends login with email/password
- Server verifies credentials
- Server returns plain text API token
- Client uses token in Authorization header
- Sanctum verifies token on each API request
- Access granted if token valid, else 401 error

Full Transcript

This visual execution shows how Laravel Sanctum handles API authentication. First, the client sends a login request with email and password. The server looks up the user by email and checks the password. If correct, Sanctum creates a plain text API token and returns it to the client. The client stores this token and sends it with future API requests in the Authorization header. Sanctum verifies the token on each request. If the token is valid, the server processes the request and returns data. If invalid, Sanctum returns a 401 Unauthorized error. This flow ensures secure API access using tokens.

Practice

1. What is the main purpose of Laravel Sanctum in API development?

easy

A. To handle frontend routing in Laravel apps

B. To provide simple token-based API authentication

C. To manage database migrations automatically

D. To optimize SQL queries for performance

Solution

1. Step 1: Understand Sanctum's role

   Sanctum is designed to provide a simple way to authenticate API requests using tokens.

2. Step 2: Compare options

   The incorrect options relate to frontend routing, database migrations, and SQL query optimization, which are other Laravel features, not Sanctum's main purpose.

3. Final Answer:

   To provide simple token-based API authentication -> Option B

4. Quick Check:

   Sanctum = API token authentication [OK]

Hint: Sanctum = simple API token auth [OK]

Common Mistakes:

• Confusing Sanctum with database or routing features
• Thinking Sanctum manages frontend or SQL optimization

2. Which of the following is the correct way to protect an API route using Sanctum middleware in Laravel?

easy

A. Route::middleware('auth:sanctum')->get('/user', function () { return auth()->user(); });

B. Route::middleware('api')->get('/user', function () { return auth()->user(); });

C. Route::middleware('sanctum')->get('/user', function () { return auth()->user(); });

D. Route::middleware('auth')->get('/user', function () { return auth()->user(); });

Solution

1. Step 1: Identify Sanctum middleware syntax

   Sanctum uses 'auth:sanctum' middleware to protect routes requiring token authentication.

2. Step 2: Check each option

   Route::middleware('auth:sanctum')->get('/user', function () { return auth()->user(); }); uses 'auth:sanctum' correctly; others use incorrect or incomplete middleware names.

3. Final Answer:

   Route::middleware('auth:sanctum')->get('/user', function () { return auth()->user(); }); -> Option A

4. Quick Check:

   Sanctum middleware = 'auth:sanctum' [OK]

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

Common Mistakes:

• Using 'auth' instead of 'auth:sanctum'
• Omitting middleware or using wrong names like 'sanctum' alone
• Confusing 'api' middleware with Sanctum middleware

3. Given this code snippet, what will be the output when a valid token is used to access the route?

use Illuminate\Http\Request;

Route::middleware('auth:sanctum')->get('/profile', function (Request $request) {
    return $request->user()->name;
});

medium

A. The name of the authenticated user

B. An error: Method user() does not exist

C. Null, because user() returns nothing

D. The user's email address

Solution

1. Step 1: Understand the middleware effect

   The 'auth:sanctum' middleware ensures the request is authenticated and $request->user() returns the authenticated user model.

2. Step 2: Analyze the return statement

   The code returns $request->user()->name, which outputs the authenticated user's name.

3. Final Answer:

   The name of the authenticated user -> Option A

4. Quick Check:

   $request->user()->name = user name [OK]

Hint: auth:sanctum gives user() object; name property outputs user name [OK]

Common Mistakes:

• Assuming user() returns null or causes error
• Confusing user name with email
• Ignoring middleware authentication effect

4. Identify the error in this code snippet for issuing a Sanctum API token:

use App\Models\User;

$user = User::find(1);
$token = $user->createToken;
return $token->plainTextToken;

medium

A. User model does not support createToken method

B. User::find(1) returns null causing error

C. plainTextToken is not a valid property

D. Missing parentheses when calling createToken() method

Solution

1. Step 1: Check method call syntax

   The createToken method must be called with parentheses and a token name string, e.g. createToken('token-name').

2. Step 2: Analyze given code

   The code uses $user->createToken without parentheses, so it references the method, not calls it, causing an error.

3. Final Answer:

   Missing parentheses when calling createToken() method -> Option D

4. Quick Check:

   Method calls need parentheses () [OK]

Hint: Always call createToken() with parentheses and token name [OK]

Common Mistakes:

• Forgetting parentheses on method calls
• Not passing token name string to createToken()
• Assuming plainTextToken is invalid

5. You want to issue a token for a user and restrict it to only allow access to 'orders' and 'products' API scopes. Which code snippet correctly creates this token with scopes using Laravel Sanctum?

hard

A. $token = $user->createToken('api-token', 'orders', 'products');

B. $token = $user->createToken('api-token')->scopes(['orders', 'products']);

C. $token = $user->createToken('api-token', ['orders', 'products']);

D. $token = $user->createToken(['orders', 'products']);

Solution

1. Step 1: Review createToken method signature

   The createToken method accepts the token name as first argument and an array of scopes as second argument.

2. Step 2: Evaluate each option

   $token = $user->createToken('api-token', ['orders', 'products']); correctly passes the token name and scopes array. $token = $user->createToken('api-token')->scopes(['orders', 'products']); incorrectly chains scopes() which does not exist. $token = $user->createToken('api-token', 'orders', 'products'); passes scopes as separate arguments, which is invalid. $token = $user->createToken(['orders', 'products']); passes scopes as first argument without token name.

3. Final Answer:

   $token = $user->createToken('api-token', ['orders', 'products']); -> Option C

4. Quick Check:

   createToken(name, scopes array) = correct [OK]

Hint: Pass scopes as second argument array in createToken() [OK]

Common Mistakes:

• Passing scopes as separate arguments instead of array
• Trying to chain scopes() method
• Omitting token name argument