API Testing interview question
How do you test API authentication and authorization (OAuth 2.0, JWT)?
Short answer
Test authentication (missing, malformed, expired, wrongly signed tokens give 401) separately from authorization (each role and scope only reaches what it should, 403 or 404 otherwise). For JWTs, check signature, exp, audience and alg handling; for OAuth, test token acquisition, scopes, refresh and revocation.
Answer
Two separate questions
- Authentication: is the caller who they claim to be? Failures should return 401.
- Authorization: is this caller allowed to do this to this resource? Failures return 403 (or 404 if the API hides existence).
Most serious API vulnerabilities are authorization bugs, so that is where I spend most of the effort.
Getting tokens in tests
For automation I avoid driving a login UI. Usually a test client uses the client credentials grant for service-to-service calls, or a test identity provider issues user tokens for seeded users with known roles. Tokens are fetched once per role and cached for the run.
String token = given()
.contentType(ContentType.URLENC)
.formParam("grant_type", "client_credentials")
.formParam("client_id", System.getenv("CLIENT_ID"))
.formParam("client_secret", System.getenv("CLIENT_SECRET"))
.formParam("scope", "orders:read")
.when()
.post(tokenUrl)
.then()
.statusCode(200)
.extract().path("access_token");
Authentication tests
- No
Authorizationheader: 401. - Wrong scheme (
BasicwhereBeareris expected), empty token, random string: 401. - Expired token: 401. Use a short-lived token from the test IdP or one signed with a test key; do not sleep for an hour.
- Tampered JWT: change a claim in the payload (for example
roletoadmin) without re-signing: 401. - Token signed by a different key, or with
algset tonone: 401. Algorithm confusion (an HS256 token signed with the RS256 public key) should also be rejected. - Wrong
aud(a token minted for another API) or wrongiss: 401. - Revoked token or token after logout, where the system supports revocation or short expiry.
- Refresh flow: a refresh token returns a new access token; a used or revoked refresh token is rejected if rotation is enabled.
JWTs are only base64url-encoded, not encrypted, so also check the payload does not contain secrets or unnecessary personal data.
Authorization tests
Build a matrix of roles and scopes against endpoints and actions:
| viewer | editor | admin | other tenant | |
|---|---|---|---|---|
| GET /projects/{id} | 200 | 200 | 200 | 403/404 |
| PUT /projects/{id} | 403 | 200 | 200 | 403/404 |
| DELETE /projects/{id} | 403 | 403 | 204 | 403/404 |
Key cases:
- Horizontal: user A requests user B’s resource by changing the id (IDOR).
- Vertical: a normal user calls admin endpoints or sets admin-only fields (
"role": "admin"in a profile update, known as mass assignment). - Scope: a token with
orders:readcannotPOST /orders. - Every method on a path, not only GET: teams often protect GET and forget PATCH.
Generate this matrix as a data-driven test so new endpoints are added to it by default.
Other checks
- Tokens never appear in URLs, logs or error messages.
- Login and token endpoints are rate limited.
- Error messages do not reveal whether a username exists.
What interviewers look for
- Clear authn vs authz distinction with the right status codes.
- Concrete JWT negative cases beyond “expired token”.
- A role/scope matrix and horizontal access (IDOR) tests.
- Practical token handling in automation without driving the login UI.
A strong answer covers
- Separates authentication (who you are) from authorization (what you can do)
- Negative token cases: missing, expired, malformed, tampered signature
- JWT claim checks: exp, aud, iss, alg none / algorithm confusion
- Role and scope matrix, including access to other users' resources
- OAuth flow details: token endpoint, refresh tokens, revocation, client credentials