Authentication for API in Wordpress - Step-by-Step Execution

Concept Flow - Authentication for API

Client sends API request

↓

Server checks for auth token

↓

Validate token

↓

Token valid?

Yes No↓

Process API

↓

Send response

The API receives a request, checks for an authentication token, validates it, and either processes the request or rejects it with an error.

Execution Sample

Wordpress

<?php
// Check for Bearer token
$headers = getallheaders();
if (!isset($headers['Authorization'])) {
  http_response_code(401); exit;
}
// Validate token
$token = str_replace('Bearer ', '', $headers['Authorization']);
if ($token !== 'valid_token') {
  http_response_code(403); exit;
}
// Process API request
http_response_code(200);
echo json_encode(['message' => 'Success']);

This PHP code snippet checks for a Bearer token in the request headers, validates it, and returns success or error codes accordingly.

Execution Table

Step	Action	Condition	Result	Response Code	Output
1	Receive API request	Authorization header present?	No	401	Exit with Unauthorized
2	Receive API request	Authorization header present?	Yes	N/A	Continue
3	Extract token	Token == 'valid_token'?	No	403	Exit with Forbidden
4	Extract token	Token == 'valid_token'?	Yes	200	Return Success message

💡 Execution stops when token is missing or invalid, sending 401 or 403 response respectively.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
$headers	empty	{Authorization: 'Bearer abc'}	{Authorization: 'Bearer abc'}	{Authorization: 'Bearer abc'}	{Authorization: 'Bearer abc'}
$token	undefined	undefined	'abc'	'abc'	'abc'
http_response_code	undefined	401 or N/A	403 or 200	403 or 200	200 or error code

Key Moments - 3 Insights

Why does the API return 401 Unauthorized instead of 403 Forbidden when the token is missing?

401 means the client did not provide authentication credentials (missing token), while 403 means credentials were provided but are invalid. See execution_table row 1 for missing token case.

What happens if the token is present but incorrect?

The API returns 403 Forbidden because the token is invalid. This is shown in execution_table row 3 where token validation fails.

Why do we remove 'Bearer ' from the Authorization header?

The Authorization header includes the word 'Bearer' followed by the token. We remove 'Bearer ' to get the actual token string to validate, as shown in the code sample.

Visual Quiz - 3 Questions

Look at the execution_table, what response code is sent when the Authorization header is missing?

A 200

B 403

C 401

D 500

💡 Hint

Check execution_table row 1 where Authorization header is missing.

At which step does the API send a 403 Forbidden response?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Look at execution_table row 3 where token validation fails.

If the token is 'valid_token', what will be the final output?

A Success message with 200 code

B 403 Forbidden

C 401 Unauthorized

D No response

💡 Hint

See execution_table row 4 where token matches and response is 200.

Concept Snapshot

Authentication for API in WordPress:
- Check for 'Authorization' header in request
- Extract token by removing 'Bearer '
- If missing, send 401 Unauthorized
- If token invalid, send 403 Forbidden
- If valid, process request and send 200 with data
Use http_response_code() to set status codes.

Full Transcript

This visual execution shows how WordPress API authentication works. When a client sends a request, the server first checks if the Authorization header is present. If missing, it sends a 401 Unauthorized response and stops. If present, it extracts the token by removing the 'Bearer ' prefix. Then it checks if the token matches the expected valid token. If not, it sends a 403 Forbidden response. If the token is valid, the server processes the API request and returns a 200 OK response with a success message. This flow ensures only authenticated clients can access the API.

Practice

1. What is the main purpose of permission_callback in WordPress REST API authentication?

easy

A. To format the API response data

B. To define the URL of the API endpoint

C. To register a new API route

D. To check if the user has permission to access the API endpoint

Solution

1. Step 1: Understand the role of permission_callback

   This callback function is used to verify if the current user has the right permissions to access a specific API route.

2. Step 2: Differentiate from other API registration parts

   Other parts like route URL and response formatting are handled separately; permission_callback specifically controls access.

3. Final Answer:

   To check if the user has permission to access the API endpoint -> Option D

4. Quick Check:

   permission_callback controls access permission [OK]

Hint: Remember permission_callback controls access rights [OK]

Common Mistakes:

• Confusing permission_callback with route registration
• Thinking permission_callback formats data
• Assuming permission_callback sets URL

2. Which of the following is the correct way to register a REST API route with authentication in WordPress?

easy

A. register_rest_route('myplugin/v1', '/data', array('methods' => 'GET', 'callback' => 'get_data', 'permission_callback' => '__return_true'))

B. register_rest_route('myplugin/v1', '/data', array('methods' => 'GET', 'callback' => 'get_data'))

C. register_rest_route('myplugin/v1', '/data', array('methods' => 'GET', 'callback' => 'get_data', 'auth_callback' => '__return_true'))

D. register_rest_route('myplugin/v1', '/data', array('methods' => 'GET', 'callback' => 'get_data', 'permission' => '__return_true'))

Solution

1. Step 1: Identify the correct parameter for authentication

   The correct parameter to control access is permission_callback, which should be set to a callable that returns true or false.

2. Step 2: Check the syntax of the registration function

   register_rest_route('myplugin/v1', '/data', array('methods' => 'GET', 'callback' => 'get_data', 'permission_callback' => '__return_true')) correctly includes permission_callback with a valid callable __return_true allowing access.

3. Final Answer:

   register_rest_route('myplugin/v1', '/data', array('methods' => 'GET', 'callback' => 'get_data', 'permission_callback' => '__return_true')) -> Option A

4. Quick Check:

   Use permission_callback for authentication [OK]

Hint: Use permission_callback, not auth_callback or permission [OK]

Common Mistakes:

• Using 'auth_callback' instead of 'permission_callback'
• Omitting permission_callback entirely
• Using 'permission' instead of 'permission_callback'

3. Given this code snippet, what will be the output when an unauthenticated user tries to access the API?

register_rest_route('myplugin/v1', '/secret', array(
  'methods' => 'GET',
  'callback' => 'get_secret_data',
  'permission_callback' => function() {
    return current_user_can('read');
  }
));

function get_secret_data() {
  return 'Secret Info';
}

medium

A. Returns a 401 Unauthorized error

B. Returns a 404 Not Found error

C. Returns an empty string

D. Returns 'Secret Info' to everyone

Solution

1. Step 1: Understand the permission_callback logic

   The callback checks if the user has the 'read' capability. Unauthenticated users do not have this capability, so it returns false.

2. Step 2: Know WordPress REST API behavior on permission failure

   If permission_callback returns false, the API returns a 401 Unauthorized error to block access.

3. Final Answer:

   Returns a 401 Unauthorized error -> Option A

4. Quick Check:

   Permission denied returns 401 error [OK]

Hint: Permission callback false means 401 error [OK]

Common Mistakes:

• Assuming data is returned without permission
• Confusing 401 Unauthorized with 404 Not Found
• Thinking empty string is returned on failure

4. Identify the error in this WordPress REST API route registration code:

register_rest_route('myplugin/v1', '/info', array(
  'methods' => 'GET',
  'callback' => 'get_info',
  'permission_callback' => 'current_user_can('read')'
));

function get_info() {
  return 'Info';
}

medium

A. The callback function 'get_info' is missing parameters

B. The 'methods' value should be an array, not a string

C. The 'permission_callback' should be a callable, not a function call string

D. The route namespace 'myplugin/v1' is invalid

Solution

1. Step 1: Check the type of permission_callback

   permission_callback must be a callable function, not the result of a function call. Here, 'current_user_can('read')' is a string calling the function immediately, which is incorrect.

2. Step 2: Correct usage of permission_callback

   It should be a callable like a function name or anonymous function that returns a boolean when called by the API.

3. Final Answer:

   The 'permission_callback' should be a callable, not a function call string -> Option C

4. Quick Check:

   permission_callback must be callable, not called [OK]

Hint: permission_callback needs a callable, not a called function [OK]

Common Mistakes:

• Passing function call result instead of callable
• Using string with quotes incorrectly
• Confusing methods string vs array

5. You want to create a WordPress REST API endpoint that only logged-in users with the 'edit_posts' capability can access. Which of these permission_callback implementations correctly enforces this?

hard

A. permission_callback => function() { return is_user_logged_in(); }

B. permission_callback => function() { return is_user_logged_in() && current_user_can('edit_posts'); }

C. permission_callback => function() { return current_user_can('read'); }

D. permission_callback => function() { return true; }

Solution

1. Step 1: Understand the requirement

   The endpoint must allow only logged-in users who have the 'edit_posts' capability.

2. Step 2: Analyze each permission_callback

   permission_callback => function() { return is_user_logged_in() && current_user_can('edit_posts'); } checks both if the user is logged in and if they have the capability, fulfilling the requirement exactly.

3. Step 3: Why other options fail

   A only checks login without the 'edit_posts' capability. B checks current_user_can('read') which many users have but not 'edit_posts'. D allows everyone.

4. Final Answer:

   permission_callback => function() { return is_user_logged_in() && current_user_can('edit_posts'); } -> Option B

5. Quick Check:

   Check login and capability together [OK]

Hint: Check both login and capability for secure access [OK]

Common Mistakes:

• Using wrong capability like 'read' instead of 'edit_posts'
• Checking only login without capability
• Allowing all users by returning true