API Authentication Types: Basic Auth, API Key, Bearer Token and OAuth 2.0

Every serious API asks one question before it does anything: who are you? That is authentication. Get it wrong and anyone can read customer data; test it badly and you’ll miss the bug that leaks it. In this lesson you will learn the four authentication methods you’ll meet in real projects (Basic auth, API keys, Bearer tokens/JWT and OAuth 2.0), where each one is used in real life, and exactly which tests to run for each one on the live practice API.

Authentication vs Authorization

This lesson covers authentication. Authorization gets its own lesson: roles and 401 vs 403.

The 4 Main Authentication Types at a Glance

Others you may meet: Digest auth (older, rarely used), HMAC signatures (AWS, payment webhooks), mutual TLS (bank-to-bank APIs) and session cookies (covered in the cookies lesson).

1. Basic Authentication

The client joins username and password with a colon, encodes it in Base64 and sends it in every request:

sqa_user:sqa@123  →  Base64  →  c3FhX3VzZXI6c3FhQDEyMw==
Authorization: Basic c3FhX3VzZXI6c3FhQDEyMw==

Practice credentials (public, for this API only): sqa_user / sqa@123.

curl -i \
  -H "Authorization: Basic c3FhX3VzZXI6c3FhQDEyMw==" \
  "https://sqatools.in/wp-json/sqa-api/v1/basic/profile"

Basic auth test cases

2. API Key Authentication

An API key is a long random string issued to an application, not to a person. The server looks it up to know which client is calling, which plan it’s on and how many calls it may make.

curl -i \
  -H "X-API-Key: sqa-key-12345" \
  "https://sqatools.in/wp-json/sqa-api/v1/apikey/profile"

API key test cases

3. Bearer Token Authentication (JWT)

The user logs in once with username and password. The server returns a short-lived access token, and the client sends it as a “bearer” in every request. “Bearer” means whoever holds this token gets access, so it must be protected like a password.

1. POST /auth/login with username and password → 200 with access_token, expires_in, refresh_token.
2. GET /auth/me with Authorization: Bearer <access_token> → 200.
3. When the access token expires, POST /auth/refresh with the refresh token → new tokens without asking for the password again.
4. POST /auth/logout → the token is revoked.

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"admin@123"}' \
  "https://sqatools.in/wp-json/sqa-api/v1/auth/login"

The practice API’s access tokens are JWTs that last 900 seconds (15 minutes). Users: admin / admin@123 (can write) and viewer / viewer@123 (read-only). JWT internals, expiry and tampering tests are covered in depth in JWT Token Testing.

Bearer token test cases

• Valid login returns a token; wrong password returns 401; missing fields return 422.
• Protected endpoint without a token → 401; with a garbage token → 401.
• Wrong scheme (Token xyz instead of Bearer xyz) → 401.
• Expired, tampered or revoked token → 401.
• The password is never echoed back; the token never appears in URLs.

4. OAuth 2.0

OAuth 2.0 is an authorization framework: it lets a user give an application limited access to their data on another service without sharing their password.

The four roles

• Resource owner: you (the user).
• Client: the app that wants access (the printing site).
• Authorization server: issues tokens (Google’s accounts server, Okta, Keycloak, Auth0).
• Resource server: the API holding the data (Google Photos API).

Common OAuth 2.0 grant types (flows)

OpenID Connect (OIDC) adds identity on top of OAuth 2.0: an ID token (a JWT) telling the app who the user is. “Login with Google” is OIDC.

OAuth 2.0 test cases

• Token request with wrong client_secret → 401 invalid_client.
• Token with scope read calling a write endpoint → 403 insufficient_scope.
• redirect_uri not on the allowed list → rejected (prevents token theft).
• state parameter checked (prevents CSRF in the login flow).
• Authorization code can be used only once and expires quickly.
• Revoked consent stops access immediately (or at token expiry).

In Postman, the Authorization → OAuth 2.0 tab can run these flows for you and store the token; you’ll use it in the Postman tutorial.

Which Authentication Should an API Use?

Automating All Auth Types with Playwright

import { test, expect } from '@playwright/test';

const BASE = 'https://sqatools.in/wp-json/sqa-api/v1';

test('Basic auth: valid and missing credentials', async ({ request }) => {
  const basic = 'Basic ' + Buffer.from('sqa_user:sqa@123').toString('base64');
  expect((await request.get(`${BASE}/basic/profile`, { headers: { Authorization: basic } })).status()).toBe(200);

  const none = await request.get(`${BASE}/basic/profile`);
  expect(none.status()).toBe(401);
  expect(none.headers()['www-authenticate']).toContain('Basic');
});

test('API key: valid, wrong and missing', async ({ request }) => {
  const url = `${BASE}/apikey/profile`;
  expect((await request.get(url, { headers: { 'X-API-Key': 'sqa-key-12345' } })).status()).toBe(200);
  expect((await request.get(url, { headers: { 'X-API-Key': 'wrong-key' } })).status()).toBe(403);
  expect((await request.get(url)).status()).toBe(401);
});

test('Bearer token: login then call a protected endpoint', async ({ request }) => {
  const login = await request.post(`${BASE}/auth/login`, {
    data: { username: 'admin', password: 'admin@123' },
  });
  expect(login.status()).toBe(200);
  const { access_token, token_type, expires_in } = await login.json();
  expect(token_type).toBe('Bearer');
  expect(expires_in).toBe(900);

  const me = await request.get(`${BASE}/auth/me`, { headers: { Authorization: `Bearer ${access_token}` } });
  expect((await me.json()).data).toMatchObject({ username: 'admin', role: 'admin', can_write: true });
});

Playwright also supports Basic auth globally through httpCredentials in the config, and you’ll learn to share a login token across tests with fixtures in Module 6.

Common Authentication Bugs

• Different error messages for “unknown user” and “wrong password” (lets attackers find valid usernames).
• No rate limit on login (brute force), or on OTP verification.
• Tokens that never expire, or that still work after logout or password change.
• Tokens or keys in URLs, logs or error messages.
• Endpoints that someone forgot to protect (often new or “internal” ones). Call every endpoint with no credentials.
• 500 errors for malformed Authorization headers.

Authentication Testing Checklist

1. Every protected endpoint returns 401 without credentials.
2. Invalid, malformed, expired and revoked credentials return 401.
3. 401 responses include WWW-Authenticate.
4. Error messages don’t reveal whether the user exists.
5. Login and key validation are rate limited.
6. Credentials travel only over HTTPS and only in headers.
7. Secrets aren’t logged, cached or returned.
8. Logout and password change invalidate tokens.

Interview Questions: API Authentication