Basic authentication in Rest API - Step-by-Step Execution

Concept Flow - Basic authentication

Client sends request with Authorization header

↓

Server receives request

↓

Server extracts Authorization header

↓

Server decodes Base64 credentials

↓

Server checks username and password

↓

Grant access

↓

Send response

The client sends credentials encoded in the Authorization header; the server decodes and verifies them, then grants or denies access.

Execution Sample

Rest API

GET /resource HTTP/1.1
Authorization: Basic dXNlcjpwYXNz

# Server decodes 'dXNlcjpwYXNz' to 'user:pass'
# Server checks credentials
# Server responds 200 OK if valid, 401 if invalid

This shows a client request with Basic Auth header and server verifying credentials.

Execution Table

Step	Action	Data	Result
1	Client sends request	Authorization: Basic dXNlcjpwYXNz	Request sent with encoded credentials
2	Server receives request	Authorization header present	Proceed to decode credentials
3	Server decodes Base64	dXNlcjpwYXNz	Decoded to 'user:pass'
4	Server splits credentials	'user:pass'	Username='user', Password='pass'
5	Server checks credentials	Username='user', Password='pass'	Credentials valid? Yes
6	Server grants access	Valid credentials	Respond with 200 OK and resource
7	End	Request handled	Process complete

💡 Execution stops after server responds based on credential validity

Variable Tracker

Variable	Start	After Step 3	After Step 4	After Step 5	Final
Authorization header	None	dXNlcjpwYXNz	dXNlcjpwYXNz	dXNlcjpwYXNz	dXNlcjpwYXNz
Decoded credentials	None	user:pass	user:pass	user:pass	user:pass
Username	None	None	user	user	user
Password	None	None	pass	pass	pass
Access granted	False	False	False	True	True

Key Moments - 3 Insights

Why does the server decode the Authorization header?

Because the credentials are sent encoded in Base64, decoding reveals the actual username and password as shown in step 3 of the execution_table.

What happens if the credentials are invalid?

The server rejects the request and sends a 401 Unauthorized response instead of granting access, which would be shown in step 5 as 'Credentials valid? No' (not shown here).

Why is the Authorization header needed in the request?

It carries the encoded username and password so the server can authenticate the client, as seen in step 1 where the client sends it.

Visual Quiz - 3 Questions

Look at the execution_table, what is the decoded credentials value at step 3?

A "user:pass"

B "dXNlcjpwYXNz"

C "Authorization: Basic dXNlcjpwYXNz"

D "user"

💡 Hint

Check the 'Data' column at step 3 in the execution_table.

At which step does the server decide if access is granted?

A Step 2

B Step 4

C Step 5

D Step 6

💡 Hint

Look for the step where credentials are checked in the execution_table.

If the password was wrong, how would the 'Access granted' variable change after step 5?

A It would be True

B It would be False

C It would be None

D It would be 'user:pass'

💡 Hint

Refer to the variable_tracker row for 'Access granted' and step 5.

Concept Snapshot

Basic authentication sends username and password encoded in Base64 in the Authorization header.
Server decodes and checks credentials.
If valid, server grants access; if not, sends 401 Unauthorized.
Used for simple client-server authentication.
Credentials are sent with every request.
Not secure without HTTPS.

Full Transcript

Basic authentication works by the client sending a request with an Authorization header containing the username and password encoded in Base64. The server receives this request, extracts the Authorization header, and decodes the Base64 string to get the username and password. It then checks these credentials against its records. If the credentials are valid, the server grants access and responds with the requested resource. If invalid, the server rejects the request with a 401 Unauthorized response. This process repeats for each request requiring authentication. The key steps are sending the encoded credentials, decoding them, verifying, and responding accordingly.