| name | testing-mobile-api-authentication |
| description | Tests authentication and authorization mechanisms in mobile application APIs to identify broken authentication, insecure token management, session fixation, privilege escalation, and IDOR vulnerabilities. Use when performing API security assessments against mobile app backends, testing JWT implementations, evaluating OAuth flows, or assessing session management. Activates for requests involving mobile API auth testing, token security assessment, OAuth mobile flow testing, or API authorization bypass.
|
| domain | cybersecurity |
| subdomain | mobile-security |
| author | mahipal |
| tags | ["mobile-security","android","ios","api-security","authentication","penetration-testing"] |
| version | 1.0.0 |
| license | Apache-2.0 |
| nist_csf | ["PR.PS-01","PR.AA-05","ID.RA-01","DE.CM-09"] |
Testing Mobile API Authentication
When to Use
Use this skill when:
- Assessing mobile app backend API authentication during penetration tests
- Testing JWT token implementation for common vulnerabilities (none algorithm, weak signing)
- Evaluating OAuth 2.0 / OIDC flows in mobile applications for redirect, PKCE, and scope issues
- Testing for broken object-level authorization (BOLA/IDOR) in API endpoints
Do not use this skill against production APIs without explicit authorization and rate-limiting awareness.
Most Often Missed & How to Confirm
- JWT
alg:none / algorithm confusion — confirm by submitting a none token or an RS256→HS256 token signed with the public key and seeing it accepted.
- Token not invalidated on logout/password change — confirm by reusing a captured token after both events; continued access is the finding.
- BOLA/IDOR — confirm by swapping object/user IDs with user A's token and retrieving user B's data.
- Token in URL — confirm by checking query strings for tokens (logged/cached) even when auth otherwise works.
- OAuth PKCE not enforced — confirm by replaying the authorization code without
code_verifier and still getting a token.
- Custom-scheme redirect hijack — confirm a second app registering the same
myapp://callback can receive the auth code.
Prerequisites
- Burp Suite or mitmproxy configured as mobile device proxy
- SSL pinning bypassed on target application (if implemented)
- Valid test account credentials for the target application
- Postman or curl for API request crafting
- jwt.io or PyJWT for JWT analysis and manipulation
Workflow
Step 1: Map Authentication Endpoints
Intercept mobile app traffic to identify authentication-related endpoints:
POST /api/v1/auth/login - Initial authentication
POST /api/v1/auth/register - Account registration
POST /api/v1/auth/refresh - Token refresh
POST /api/v1/auth/logout - Session termination
POST /api/v1/auth/forgot-password - Password reset
POST /api/v1/auth/verify-otp - OTP verification
GET /api/v1/auth/me - Authenticated user profile
Step 2: Analyze Token Format and Security
JWT Analysis:
| -d. -f2 | -d 2>/dev/null
hashcat -m 16500 jwt.txt wordlist.txt
