API Authentication Methods

Hello and welcome back to your bug bounty training!

In our last lesson, we focused on discovering API endpoints by analyzing traffic and digging into client-side JavaScript files. This gave you a map of the application's attack surface. Now, we need to understand the gates and guards that protect those endpoints.

This lesson directly addresses the learning outcome: Differentiate between common API authentication patterns like API Keys, Bearer Tokens (JWT), and OAuth.

Understanding how an API authenticates requests is a fundamental step in penetration testing. Each pattern has a different architecture, different trust models, and, most importantly, a different set of common vulnerabilities. Recognizing the pattern you're up against allows you to focus your testing efforts on the most likely weaknesses.

We will explore:

• API Keys: The simplest form of authentication, often used for server-to-server communication.
• JWT Bearer Tokens: A modern, stateless method for authenticating users in web and mobile apps.
• OAuth 2.0: A comprehensive framework for delegated authorization, commonly seen in "Login with Google/Facebook" features.

1. The Big Picture: Authentication vs. Authorization

Before diving into the specific mechanisms, it's crucial to solidify the difference between two terms that are often used interchangeably: authentication and authorization. Given your computer science background, you'll recognize this as a core security principle.

• Authentication is about proving identity. It answers the question, "Who are you?"
• Authorization is about granting permissions. It answers the question, "What are you allowed to do?"

An API must first authenticate a request to identify the user or application, and then authorize that identity to perform the requested action. The methods we'll discuss handle these concepts in different ways.

To get a high-level overview of the three main authentication patterns, let's start with a short video.

Now, let's break down each of these patterns from a security tester's perspective.

2. API Keys: The Static Secret

API Keys are the most straightforward authentication method. An API key is typically a long, randomly generated string that you include in your request to identify your client application.

From a pentester's viewpoint, the key characteristic of this method is its static nature. An API key is like a password for an application; if it's leaked, it can be used by anyone until it's revoked by the server administrator.

How to Spot and Test API Keys:

• Identification: Look for custom HTTP headers like X-API-Key, X-Api-Key, or a key in the Authorization header, sometimes without the Bearer prefix. You might also find them passed as URL query parameters (?api_key=...), though this is less secure and less common.
• Key Characteristic: They are static and typically identify an application or project, not a specific user. This means they often grant broad permissions.
• Primary Vulnerability: Leakage. Your reconnaissance skills from the previous lesson are critical here. Hunt for API keys in:
  • Client-side JavaScript files.
  • Mobile application code.
  • Public code repositories (e.g., GitHub).
  • Configuration files exposed through other vulnerabilities.

3. JWT Bearer Tokens: The Stateless ID Card

JSON Web Tokens (JWTs) are the dominant standard for securing APIs for Single Page Applications (SPAs) and mobile apps. A JWT is a "Bearer" token, meaning the "bearer" (whoever holds the token) is granted access.

The token itself is a long string made of three Base64Url-encoded parts separated by dots: header.payload.signature. The payload contains "claims" about the user, such as their user ID, role, and the token's expiration time. The signature ensures that the token hasn't been tampered with.

How to Spot and Test JWTs:

• Identification: Look for an Authorization: Bearer ey... header. The token string almost always starts with ey because it's the Base64Url encoding of {"alg":...}. You can copy the token string and paste it into a decoder like jwt.io to inspect its contents.
• Key Characteristic: Stateless and self-contained. The server doesn't need to store session information, which simplifies scaling. All necessary user info is in the token.
• Primary Vulnerabilities (Preview): The payload is encoded, not encrypted, so never put sensitive data in it. The security of the token relies entirely on the signature. Common attacks, which we'll cover in-depth in Module 10, include:
  • Exploiting weak secret keys used for signing.
  • Signature stripping (the alg: 'none' attack).
  • Tampering with the claims in the payload if the signature validation is weak.

4. OAuth 2.0 & OIDC: Delegated Access

OAuth 2.0 is the most complex of the three. It is an authorization framework, not just an authentication protocol. Its primary purpose is to allow a user to grant a third-party application limited access to their data on another service, without sharing their password. Think of any time you've used a "Login with Google" or "Connect your GitHub account" button.

OpenID Connect (OIDC) is an authentication layer built on top of OAuth 2.0. While OAuth 2.0 provides an access_token (for authorization), OIDC adds an id_token (which is a JWT) that contains information about the authenticated user. In practice, when you see a "social login" button, you are typically using OIDC.

Because of its complexity, OAuth has many moving parts and several different "flows" (sequences of steps) for different use cases. Understanding these flows is key to testing them.

How to Spot and Test OAuth/OIDC:

• Identification: The user is redirected from the application (client) to an identity provider's domain (e.g., accounts.google.com, auth.okta.com). The URL will contain parameters like client_id, redirect_uri, scope, state, and response_type=code.
• Key Characteristic: Delegated authorization. The application never sees the user's password for the identity provider. It receives a temporary code and exchanges it for an access_token on the backend.
• Primary Vulnerabilities:
  • Insecure redirect_uri: If not strictly validated, an attacker can manipulate it to an evil domain, causing the code or token to be leaked.
  • CSRF on the login flow: If the state parameter is missing or not validated, an attacker can trick a user into logging into the attacker's account.
  • Authorization Code Interception/Re-use: Stealing the code from a legitimate user and using it to get an access_token.

Test your understanding!

You are testing a web application and observe three distinct API calls. For each, identify the most likely authentication mechanism and name one specific security concern you would immediately focus on.

1. A request to https://api.weather-provider.com/v1/forecast?zip=90210&key=a1b2c3d4e5f6...
2. A POST request to your application's /api/user/settings endpoint with the header: Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxMjMsInJvbGUiOiJ1c2VyIiwiZXhwIjoxNjc3NjI5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
3. Clicking a "Login" button sends you to https://auth.corp-sso.com/authorize?response_type=code&client_id=my-app-123&scope=openid%20profile&redirect_uri=https://my-app.com/callback

Show answer

1. Mechanism: API Key. The key is being passed directly in the URL as a query parameter.

   • Security Concern: Key Leakage. Since the key is in the URL, it's more likely to be logged by browsers, proxy servers, or found in Referer headers. My primary goal would be to see if this key is generic and if I can find it hardcoded elsewhere (like in the app's public JS files).

2. Mechanism: JWT Bearer Token. The Authorization: Bearer header and the ey... format with three parts are clear indicators of a JWT.

   • Security Concern: Sensitive Data Exposure in Payload. I would immediately copy the token payload (the middle part) and Base64-decode it to see what information it contains. Does it have personally identifiable information (PII), user roles I could try to tamper with, or other sensitive data that shouldn't be exposed on the client side?

3. Mechanism: OAuth 2.0 / OpenID Connect. The redirect to an external authorization server and the presence of response_type=code, client_id, and redirect_uri are classic signs of an OAuth Authorization Code Flow. The scope=openid suggests it's also OIDC.

   • Security Concern: Insecure redirect_uri validation. My first test would be to see if I can change the redirect_uri to a domain I control. If the server doesn't properly validate the URI, it might redirect the user to my malicious site with the sensitive authorization code in the URL, allowing me to hijack their session.

Conclusion

You can now distinguish between the three most common API authentication patterns you'll encounter in the wild. This ability to classify the protection mechanism is the first step toward breaking it.

Key Takeaways:

• API Keys are static secrets that identify an application. You find them by hunting for leaked secrets.
• JWTs are self-contained bearer tokens that identify a user. You spot them by the Bearer ey... header and test them for signature weaknesses and information disclosure in the payload.
• OAuth/OIDC is a complex authorization framework involving redirects. You identify it by the redirect flow and test it for weaknesses in parameter handling, especially the redirect_uri.

Next Lesson Preview:
This lesson concludes our module on Web Application Analysis and Mapping. You now know how to map an application's surface and identify its core authentication mechanisms. In our next module, "Authentication & Session Management Flaws," we will put this knowledge into practice. Our very first lesson will be to analyze authentication flows to identify weaknesses such as insecure credential handling and lack of rate limiting, building directly on what you've learned today.