Understanding Authorization in Postman: A Complete Guide for QA Engineers

Authorization is a critical aspect of API testing, ensuring that only authorized users or systems can access the desired resources. For QA engineers working with Postman, understanding how to implement and test different authorization methods is essential for validating API security and functionality.

This article explores the concept of authorization in Postman, highlights its types, and provides real-world examples of how to use each type.

What is Authorization in Postman?

In Postman, authorization is the process of granting access to APIs based on credentials, tokens, or permissions. It ensures that only those with the proper rights can perform actions or retrieve information from an API.

Why is Authorization Important?

• Data Security: Prevents unauthorized access to sensitive data.
• Access Control: Differentiates roles and permissions.
• Compliance: Meets security standards and legal requirements.

Commonly used types of Authorization

1. No Authorization

"No Authorization" in Postman is an option that indicates no authentication is required to access an API endpoint. When this option is selected, Postman sends the API request without any credentials or authentication headers. It is primarily used for testing public APIs or endpoints that are accessible to everyone without restrictions.

2. API Key Authorization

API Key authorization is a simple and widely used method for authenticating requests to APIs (Application Programming Interfaces). It involves using a unique key, provided by the API provider, to validate the client making the request. This key acts as a token of identity, granting access to specific resources or services on the API server.

3. Basic Authorization

Basic Authorization is one of the simplest and most widely supported methods of API authentication. It involves sending a user's username and password in an HTTP request's Authorization header. While it's straightforward to implement and test, it is often less secure and is typically combined with HTTPS to prevent credential exposure.

4. Digest Authorization

Digest Authentication is a safer way to verify users on the web compared to Basic Authentication. Instead of sending usernames and passwords in plain text (which can be intercepted easily), Digest Authentication transforms these credentials into a unique, encrypted form before sending them over the network. This makes it much harder for attackers to steal sensitive information.

5. OAuth 1.0a Authorization

OAuth 1.0a is an authorization framework that enables applications to securely access user data on a server without exposing the user's credentials (username and password). OAuth 1.0 is a widely accepted method for delegating authorization, meaning it allows one service (like a website) to access resources on behalf of a user on a different service (like social media accounts) without requiring direct password sharing.

How OAuth 1.0 Works

Request Token

• The client sends a request to the Authorization Server to obtain a temporary Request Token.
• This Request Token acts as a placeholder before getting full access.

User Authorization

• The user is redirected to the Authorization Server to grant access to the client application.
• After approval, the user authorizes access.

Access Token

• The client exchanges the Request Token for an Access Token.
• The Access Token allows the client to access protected resources on the Resource Server without using the user's login credentials.

6. OAuth 2.0 Authorization

OAuth 2.0 is a popular system that helps apps securely access a user's data without needing to know their password. Instead of sharing usernames and passwords, OAuth 2.0 uses special tokens to grant access. This approach is easier to set up and more secure than its older version, OAuth 1.0, making it a preferred choice for modern web and mobile applications.

How OAuth 2.0 Works

OAuth 2.0 enables secure access to resources by exchanging tokens instead of sharing user credentials. Here’s a simplified breakdown of how it works:

1. User Initiates Interaction A user clicks a "Sign in with Google" button, for instance, to log into an app. The goal is to authenticate the user without sharing their password directly with the app.
2. Redirect to Authorization Server The user is redirected to the OAuth provider (Google, Facebook, etc.) where they authenticate and approve access to their data.
3. Authorization Grant Exchange After authentication, the OAuth provider sends an authorization code back to the client application. The client then exchanges this code for an access token, which allows access to user data.
4. Token Use The client application uses the access token to make secure API requests to the resource server, fetching data on behalf of the user.
5. Resource Access and Consent Handling The resource server checks the token's validity and grants access to the requested resources only if the token is valid and not expired.
6. Refresh Token (Optional) OAuth 2.0 can also provide a refresh token. This token helps maintain long-term access by refreshing the access token without forcing the user to log in again.