HTTP - Authentication and Authorization

Quiz

Authentication and Authorization are the two essential part of web communication. Authentication is used to verify the identity of a user, while authorization is used to determine their permissions and access levels. This chapter covers various HTTP Authentication and Authorization schemes.

Basic Authentication

Basic Authentication is an authentication mechanism where the user's credentials such as user name and password is encoded in Base64 and sent with HTTP request. It is generally paired with HTTPS to encrypt the communication.

Working of Basic Authentication

First, the client makes a request to server for any resource.
The server responds with 401 Unauthorized status code and WWW-Authenticate: Basic header if authentication is required for the request made by the client.
Upon receiving the 401 Unauthorized status code, client sends the request with authorization header which consist of Basic and the Base64-encoded information.

Example 1

In this example we have sent the request without using Authorization header which results in 401 UNAUTHORIZED.

GET https://httpbin.org/basic-auth/ravi/abcde HTTP/1.1
User-Agent: PostmanRuntime/7.43.0
Accept: */*

Output

Example 2

This example sends an HTTP request with Authorization header.

GET https://httpbin.org/basic-auth/ravi/abcde HTTP/1.1
User-Agent: PostmanRuntime/7.43.0
Accept: */*
Authorization: Basic cmF2aTphYmNkZQ==

Output

Advantages of Basic Authentication

It is simple to implement.
It is supported by all HTTP clients.

Limitations of Basic Authentication

It is not secure as credential sent is in form base64 in Authorization header which can easily be decoded.
It is paired with HTTPS for encryption to ensure the security aspect.

Digest Authentication

HTTP Digest Authentication is a challenge response authentication mechanism where credentials is secured by hashing them. It provides better security than basic authentication, as it does not transmit the password in plaintext.

Working of Digest Authentication

Initially, client makes a request to server.
The server responds with 401 Unauthorized status and a WWW-Authenticate header containing a nonce, realm, and algorithm details.
Client uses this with its own username and password for generating a hashed response.
Then, server validates the hashed response to grant or deny access without transmitting the password in plaintext.

Example 1

In this example we have sent the request without using Authorization header which results in 401 UNAUTHORIZED.

GET https://httpbin.org/digest-auth/auth/user/passwd HTTP/1.1
User-Agent: PostmanRuntime/7.43.0
Accept: */*

Output

Example 2

This example sends an HTTP request with Authorization header.

GET https://httpbin.org/digest-auth/auth/ravi/abcde HTTP/1.1
User-Agent: PostmanRuntime/7.43.0
Accept: */*

In Authorization tab
Auth Type: Digest Auth
Username: ravi
Password: abcde

Output

Advantages of Digest Authentication

It enhances the security using hashing.
It uses nonces to prevent replay attacks..

Limitations of Digest Authentication

Computational overhead for hashing using the server response.
It has limited adoption.

Bearer Tokens

Bearer token authentication is a token authentication where tokens generated by server is used to get access to any resource. Without this token, server will respond with 401 UNAUTHORIZED. Tokens are included in the Authorization header of the request.

Working of Bearer Tokens

Client sends an authentication request with username and password to url or server.
The server validates the credentials and responds with 200 OK status code and token.
Client include this token in Authorization header and sends the HTTP request.
Server validates the token and responds with 200 OK status code if the token matches. If the token is invalid then it responds with 401 UNAUTHORIZED.

Example 1

In this example we have sent the request without using Authorization header which results in 401 UNAUTHORIZED.

GET https://httpbin.org/bearer HTTP/1.1
User-Agent: PostmanRuntime/7.43.0
Accept: */*
Accept-Encoding: gzip, deflate

Output

Example 2

This example sends an HTTP request with Authorization header.

GET https://httpbin.org/bearer HTTP/1.1
User-Agent: PostmanRuntime/7.43.0
Accept: */*
Accept-Encoding: gzip, deflate
Authorization: Bearer randomtoken

Output

Advantages of Bearer Tokens

Bearer tokens are easy and simple to implement.
Tokens have expiry time and can be revoked in case of any security breach.

Limitations of Bearer Tokens

Tokens are harder to track and revoke as they are stateless and is not stored on server side.
Tokens need to be stored securely.

OAuth 2.0

OAuth 2.0 is an authorization framework allowing a third party application to access limited resources without revealing user credentials. It uses access tokens for secure resource access.

Components of OAuth2.0

Resource Owner: The owner of the resource granting access to authorization server.
Resource Server: The server where requested resource by client is present and it validates the tokens granting access to the requested resource.
Client: It represents the application that requests access to the resource in place of the user.
Authorization Server: This server gets the consent of resource owner and is responsible for providing the tokens after authenticating the client.

Working of OAuth 2.0

First the Client makes request to Authorization Server to access the resource in Resource Server.
The Resource Owner grants permission to Authorization Server to access the Resource Server and the Authorization Server provides an authorization code.
The Client then sends the authorization code to the authorization Server's token endpoint with its credentials for getting the access token.
The Client then includes this access token in the Authorization header of API requests to access the resources.
The Resource Server then validates the token and checks permissions before granting access to the requested resource.

Advantages of OAuth 2.0

It provides secure way of authorization of external services and does share user's credentials.
It supports token expiry time and revocation.
It offers various grant types which allow flexibility to handle authentication and authorization based on different scenarios.

Limitations of OAuth 2.0

Complex implementation.
Need to coordinate among different parties.
Tokens needs to be securely stored on both side i.e client side and server side. If not stored properly, it can lead to token leakage or unauthorized access.

Cookie-based Authentication

Cookie based Authentication stores session ID in cookies to authenticate users. Then for subsequent requests, this cookie is used for authentication automatically rather than users entering credential every time with each request.

Working of Cookie-based Authentication

User submits the login form and the credentials is submitted to the server.
The server then creates a session and stores the session ID and sends it to client/user.
This session ID is stored at client side as cookie.
The client then use this cookie in subsequent requests to authenticate.

Example

Setting the Cookie

GET https://httpbin.org/cookies/set?cookie=tp HTTP/1.1
User-Agent: PostmanRuntime/7.43.0
Accept: */*
Accept-Encoding: gzip, deflate

Output

Getting the Cookie

GET https://httpbin.org/cookies HTTP/1.1
User-Agent: PostmanRuntime/7.43.0
Accept: */*
Accept-Encoding: gzip, deflate

Output

Advantages of Cookie-based Authentication

It offers automatic session management where cookies is sent automatically with each request.
Cookie can be set with a expiration time so that user can navigate to different page or even close and reopen the browser.
Cookies supports features such as SameSite, HttpOnly, and Secure attributes for better security.

Limitations of Cookie-based Authentication

It is vulnerable to attack CSRF(Cross-Site Request Forgery).
Cookies have a storage limitations of 4kb which can not store for large user sessions or complex data.
Cookie based authentication is dependent on the client side browser which can interfere with or block cookie usage.

Print Page