From Duplicate to Discovery: Why API Authentication Is Not Authorization + Video

By /

Listen to this Post

Featured Image

Introduction:

In the world of API security testing, few moments are as deflating as receiving a “Duplicate” notification on a bug bounty report. Yet hidden within that triage response often lies a lesson more valuable than any payout. The distinction between authentication (proving who you are) and authorization (determining what you can access) represents one of the most misunderstood concepts in web application security—and one of the most frequently exploited. When a security researcher assumes an endpoint is vulnerable based solely on its URL structure, they risk overlooking the actual authorization mechanism that governs access. This article explores the critical difference between authentication and authorization, provides hands-on testing methodologies, and demonstrates how every “duplicate” report can become a stepping stone toward mastery.

Learning Objectives:

  • Differentiate between authentication and authorization in API security contexts
  • Identify common API authentication mechanisms and their associated vulnerabilities
  • Execute practical API security tests using curl, Burp Suite, and OWASP ZAP
  • Understand and mitigate JWT-specific attacks including algorithm confusion and `alg:none` exploits
  • Apply OWASP API Security Top 10 principles to real-world penetration testing scenarios

You Should Know:

1. Authentication vs. Authorization: The Core Distinction

The security researcher’s experience highlights a fundamental truth: an endpoint might look like it exposes user information, but the real question is what actually authorizes the request? In their case, the application relied on a valid Authorization Bearer Token rather than trusting values in the URL—a distinction that completely changed how the issue should be analyzed.

Authentication answers “Who are you?” while authorization answers “What are you allowed to do?”. An API can successfully authenticate a user (verify their identity via a token, API key, or credentials) yet still fail to properly authorize that user’s access to specific resources. This is precisely what enables Broken Object Level Authorization (BOLA)—ranked as OWASP API1:2023, the single most critical API security risk.

Consider this scenario: An e-commerce API allows viewing order details through an `/orders/{order_id}` endpoint. If changing the order ID from one number to another returns another customer’s complete order—including name, address, and payment information—the API has failed at authorization despite successful authentication. The T-Mobile breach of 2023 exposed 37 million customer records through exactly this type of authorization failure: the API authenticated users but never verified whether they had permission to access specific data.

Step-by-Step Testing Approach:

  1. Map the API attack surface using OpenAPI specifications, Swagger files, and Postman collections. Proxy your web and mobile applications through Burp Suite or OWASP ZAP to capture actual API traffic.

  2. Document all authentication mechanisms—OAuth 2.0, JWT tokens, API keys, or Basic Auth. Note where credentials are transmitted, token lifespans, and revocation processes.

  3. Create multiple test accounts (at least two regular users and one administrator) to test cross-account access.

  4. Modify object identifiers in URL parameters, request bodies, and headers to test if one user can access another user’s resources.

2. Common API Authentication Mechanisms and Their Weaknesses

Modern APIs employ various authentication methods, each with distinct security considerations:

Bearer Tokens (JWT): JSON Web Tokens are compact, URL-safe security tokens containing signed claims. They are transmitted via the `Authorization: Bearer ` header. However, JWTs are vulnerable to several attack vectors:
– `alg:none` attacks: Changing the JWT header to `{“alg”:”none”}` may cause some servers to accept unsigned tokens
– Algorithm confusion: Swapping RS256 to HS256 with a weak secret
– Weak secret brute force: Using tools like `jwtcrack`
– Claim abuse: Modifying token claims (e.g., role: admin) to bypass access controls

OAuth 2.0: The standard for API protection and federated login. Common misconfigurations include:
– Weak `redirect_uri` validation allowing attackers to redirect authorization codes to malicious servers
– OAuth tokens or codes passed in URLs remaining in browser history and leaking via the Referer header
– Improper scope enforcement enabling privilege escalation

API Keys: Should never be used for user authentication—only for client app/project identification. Best practice dictates transmitting API keys in the Authorization header using the Bearer scheme: Authorization: Bearer YOUR_API_KEY.

Testing Commands:

 Linux/macOS - Test Bearer Token Authentication
curl -X GET https://api.example.com/api/v1/users/me \
-H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." \
-H "Content-Type: application/json"

Test with verbose output to see full request/response
curl -v -X GET https://api.example.com/api/v1/users/123 \
-H "Authorization: Bearer $TOKEN"

Test JWT alg:none vulnerability
 Decode JWT header (Base64)
echo "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9" | base64 -d

Attempt alg:none attack (modify header to {"alg":"none"})
 Use Burp Suite or jwt_tool for automated testing

 Windows PowerShell - Bearer Token Authentication
$headers = @{
Authorization = "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
"Content-Type" = "application/json"
}
Invoke-RestMethod -Uri "https://api.example.com/api/v1/users/me" -Headers $headers -Method Get

3. JWT Attack Vectors and Mitigation Strategies

JWT vulnerabilities consistently appear in OWASP Top 10 findings and real-world bug bounty reports. Understanding these attack vectors is essential for both offensive and defensive security professionals.

Common JWT Attacks:

| Attack Vector | Description | Impact |

||||

| `alg:none` | Header set to "alg":"none"; server accepts unsigned tokens | Complete token forgery |
| Algorithm Confusion | RS256 → HS256 swap with weak secret | Token manipulation |
| Weak Secret Brute Force | Brute-forcing HMAC secrets with `jwtcrack` | Token forgery |
| JWK Injection | Malicious JSON Web Key via `jku` or `kid` | Server-side compromise |
| Claim Manipulation | Modifying role, user_id, or `exp` claims | Privilege escalation |

Step-by-Step JWT Testing Methodology:

  1. Intercept a request containing a JWT (typically in the Authorization header, cookies, or query parameters).

  2. Decode the JWT using Burp Suite’s JWT Editor extension or online tools like jwt.io. Examine the header and payload for suspicious claims.

  3. Test alg:none: Modify the header to {"alg":"none"}, remove the signature segment, and resend the request.

  4. Test algorithm confusion: If the server uses RS256, try changing to HS256 and signing with the public key.

  5. Attempt claim modification: Change `role` from `user` to `admin` or modify `user_id` to access another user’s data.

Mitigation Commands and Configuration:

 Python - Secure JWT validation with PyJWT
import jwt
from jwt.exceptions import InvalidTokenError

def validate_jwt(token, public_key):
try:
 Explicitly allow only RS256
payload = jwt.decode(
token,
public_key,
algorithms=["RS256"],  Whitelist, not blacklist
audience=["api.example.com"],
issuer=["auth.example.com"],
options={"require": ["exp", "iat", "iss", "aud"]}
)
return payload
except InvalidTokenError as e:
print(f"Invalid token: {e}")
return None

// Node.js - Express JWT validation
const jwt = require('jsonwebtoken');

const validateJWT = (req, res, next) => {
const token = req.headers.authorization?.split(' ')[bash];
if (!token) return res.status(401).json({ error: 'No token provided' });

try {
const decoded = jwt.verify(token, process.env.JWT_PUBLIC_KEY, {
algorithms: ['RS256'], // Explicit whitelist
issuer: 'auth.example.com',
audience: 'api.example.com'
});
req.user = decoded;
next();
} catch (err) {
res.status(403).json({ error: 'Invalid token' });
}
};

4. OAuth 2.0 Security Testing: The redirect_uri Vulnerability

OAuth 2.0 implementations frequently suffer from inadequate `redirect_uri` validation—a well-known requirement that remains widely overlooked. In a 2025 bug bounty engagement, a researcher manipulated the `redirect_uri` parameter to leak complete JWT authentication tokens to an attacker-controlled Burp Collaborator server, leading to full account takeover.

Step-by-Step OAuth Testing Methodology:

Phase 1: Discovery and Interception

  1. Configure Burp Suite proxy (default: 127.0.0.1:8080) with intercept turned ON.
  2. Navigate to the application and click “Login with 
    ".</li>
</ol>

<h2 style="color: yellow;">3. Intercept the authorization request.</h2>

<h2 style="color: yellow;">Phase 2: Testing redirect_uri Validation</h2>

<h2 style="color: yellow;">4. Identify OAuth parameters in the intercepted request:</h2>

[bash]
GET /authorize?response_type=code&client_id=3128979333002483118&
redirect_uri=https://support.target.com/callback&scope=openid%20profile&state=random_value

    5. Modify the `redirect_uri` to an external domain you control:

    redirect_uri=https://attacker.com

    6. Test bypass techniques:

    • Subdomain abuse: `redirect_uri=https://attacker.com.target.com`
    • Path traversal: `redirect_uri=https://target.com/callback/../attacker`
    • Open redirect chaining: `redirect_uri=https://target.com/redirect?url=https://attacker.com`
    • URL encoding: `redirect_uri=https://target.com%252eattacker.com`

    Phase 3: Exploitation with Burp Collaborator

    1. Set up Burp Collaborator and copy your unique URL (e.g., `https://xxxxxxxxxxxxx.oastify.com`).

    8. Replace the `redirect_uri` with your Collaborator URL.

    1. Deliver the malicious link and monitor Collaborator for incoming interactions.

    2. API Penetration Testing with Burp Suite and OWASP ZAP

    Modern API security testing requires a combination of automated scanning and manual verification. Automated scanners often miss business logic flaws—the very vulnerabilities that lead to major breaches.

    Burp Suite Extensions for API Testing:

    • Repeater2: Combines NoAuth, JWT Attacker, and AuthzTester into a single workflow for authorization testing, JWT security analysis, and multi-user access control validation.
    • JWT Scanner: Automatically detects JWTs in requests and performs automated security testing.
    • JWTLens: Performs 56 security checks covering the complete JWT attack surface—from passive analysis to active exploitation of signature bypasses and algorithm confusion.
    • OpenAPI-Bifrost: Bridges OpenAPI specifications and sends parsed endpoints to Scanner, Repeater, and Intruder with a built-in RBAC comparison grid.

    OWASP ZAP: A free alternative to Burp Suite Professional with CI/CD integration.

    Practical Testing Commands:

     Linux - Basic API reconnaissance
 Enumerate API endpoints with ffuf
ffuf -u https://api.example.com/api/v1/FUZZ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -fc 404

Test for BOLA - modify user ID in URL
curl -X GET https://api.example.com/api/v1/users/123/profile \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json"

Test for BOLA - modify user ID in request body
curl -X POST https://api.example.com/api/v1/orders \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{"user_id": "456", "product": "item"}'

Test IDOR via parameter manipulation
curl -X GET "https://api.example.com/api/v1/documents?doc_id=789" \
-H "Authorization: Bearer $TOKEN"

     Windows PowerShell - API testing
$token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
$headers = @{ Authorization = "Bearer $token" }

Test different user IDs
1..10 | ForEach-Object {
$uri = "https://api.example.com/api/v1/users/$_/profile"
try {
$response = Invoke-RestMethod -Uri $uri -Headers $headers -ErrorAction Stop
Write-Host "User $_ accessible" -ForegroundColor Green
} catch {
Write-Host "User $_ not accessible" -ForegroundColor Red
}
}

    6. API Security Best Practices and Hardening

    Based on OWASP guidance and industry best practices, secure API implementations should adhere to the following principles:

    1. Always use HTTPS/TLS for all API communication.

    1. Implement strong authentication: Use OAuth 2.0 or OpenID Connect with proper authorization server configuration. Never send sensitive authentication details (tokens, passwords) in URLs.

    2. Enforce strict authorization checks at every endpoint. Authentication verifies identity; authorization determines access.

    4. Validate JWT tokens rigorously:

    • Explicitly whitelist allowed algorithms (never accept alg:none)
    • Validate all claims: issuer, subject, audience, expiration
    • Set short expiration times (5-15 minutes for access tokens)
    • Use EdDSA (Ed25519) or ES256 for signing; avoid weak algorithms

    1. Implement rate limiting and throttling to prevent brute force attacks.

    2. Validate the `redirect_uri` parameter in OAuth flows against a pre-registered whitelist—exact matching, not prefix-based.

    7. Rotate and revoke keys regularly.

    1. Use established libraries with secure defaults—never implement custom JWT or authentication logic.

    What Undercode Say:

    • “Never assume an endpoint is vulnerable based on its URL alone. The real question is what actually authorizes the request.”

    • “Good security testing isn’t about proving yourself right—it’s about understanding how the application actually works.”

    Every triage response, whether Duplicate, Informative, or Accepted, provides feedback that refines your methodology. Bug bounty isn’t just about collecting payouts; it’s about learning to think like a security engineer. The best reward isn’t always the payout—sometimes it’s leaving the assessment with a better understanding than when you started. In an era where authentication and authorization failures remain primary attack vectors across industries—as demonstrated by breaches affecting T-Mobile, Optus, and Allianz Life—this mindset is what separates effective security professionals from those who merely run tools.

    Prediction:

    • +1 The growing adoption of Zero Trust architectures will drive increased investment in API security testing, creating more opportunities for skilled penetration testers and bug bounty hunters over the next 3-5 years.

    • -1 As APIs become the primary attack surface for modern applications, authentication and authorization failures will continue to dominate breach statistics unless organizations prioritize security testing throughout the development lifecycle.

    • +1 AI-powered API security testing tools will augment—but not replace—manual testing, as business logic flaws and authorization issues remain beyond the reach of automated scanners.

    • -1 The proliferation of undocumented “shadow APIs” and microservices with inconsistent security controls will create new vectors for authentication bypass attacks, demanding more comprehensive API inventory and governance.

    • +1 The IETF’s updated JWT Best Current Practices (RFC 8725bis) will drive improved token security standards, reducing the prevalence of algorithm confusion and `alg:none` attacks across the industry.

    ▶️ Related Video (88% Match):

    https://www.youtube.com/watch?v=4XnvyN0i8H0

    🎯Let’s Practice For Free:

    🎓 Live Courses & Certifications:

    Join Undercode Academy for Verified Certifications

    🚀 Request a Custom Project:

    Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
    [email protected]
    💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

    IT/Security Reporter URL:

    Reported By: Ryaan Paul – Hackers Feeds
    Extra Hub: Undercode MoN
    Basic Verification: Pass ✅

    🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

    💬 Whatsapp | 💬 Telegram

    📢 Follow UndercodeTesting & Stay Tuned:

    𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: