API authentication establishes who or what is making a request; authorization decides what that identity may do. Strong login controls cannot compensate for an endpoint that returns another customer’s record, and a correct role check cannot protect a stolen or improperly validated token.
A complete API security assessment tests both layers across every transport and identity type. It covers user sessions, OAuth clients, service accounts, API keys, webhooks and machine workloads, then verifies object, function, field and workflow permissions at the resource-owning service.
Authentication and authorization are different controls
Authentication failures enable impersonation, while authorization failures let a valid identity exceed its permissions. Testers should build an explicit matrix of identities, roles, tenants, objects and actions, then exercise negative cases instead of assuming the API specification describes enforcement.
Key risk areas
1. Token validation
Test signatures, issuer, audience, expiry, not-before, algorithms and key rotation. A token that is merely decoded rather than fully validated can be forged or replayed.
2. Session lifecycle
Verify logout, revocation, idle and absolute timeouts, device changes and concurrent sessions. Password resets and role changes should invalidate affected access where policy requires.
3. Object-level authorization
Replace record identifiers using same-role users and different tenants. The service must derive ownership from trusted identity and verify access for every read and write.
4. Function-level authorization
Call administrative or internal endpoints directly with ordinary credentials. Hiding a button or route in the client is not an authorization control.
5. Property-level authorization
Attempt to read or set sensitive fields such as roles, account ownership, prices and approval state. Use allowlists for accepted and returned properties.
6. OAuth and delegated access
Check redirect URI matching, state and PKCE, scope enforcement, consent, token exchange and refresh-token handling. Bind delegated rights to the intended client and resource.
7. Service identities and API keys
Inventory machine credentials, owners and scopes. Test rotation, environment separation, source restrictions and whether leaked keys reveal excessive capability.
8. Workflow authorization
Attempt to skip approvals, reorder steps, replay operations or reuse a token after the business context changed. Each transition needs server-side checks.
Step-by-step testing methodology
Step 1: Inventory entry points and identities
Collect API specifications, mobile and web traffic, gateway routes, webhooks and background jobs. Map every authentication method and trust boundary.
Step 2: Build an access-control matrix
List roles and service identities against objects, fields and actions. Include ownership, tenant and state requirements, then mark expected allow and deny outcomes.
Step 3: Test token acceptance
Alter algorithms, claims, audiences, issuers, timestamps and key identifiers using safe test tokens. Verify consistent enforcement across gateways and services.
Step 4: Test session and credential lifecycle
Exercise login, refresh, logout, password reset, role change, key rotation and revocation. Check queued jobs and caches for continued access.
Step 5: Test horizontal authorization
Use two equivalent users and tenants to exchange object identifiers across reads, writes, downloads and bulk endpoints.
Step 6: Test vertical authorization
Call privileged functions and fields with lower roles through all verbs, content types and versioned routes.
Step 7: Test delegated and machine access
Reduce or expand scopes, change resources and clients, and verify service credentials cannot cross intended environments.
Step 8: Validate monitoring
Confirm failed authentication, cross-tenant denials, unusual token use and privileged operations create useful, protected audit records.
Planning a safe assessment
Use written authorisation, representative staging accounts and agreed stop conditions. Map users, service identities, data classes, APIs and third-party dependencies before testing. Separate ordinary, privileged and cross-tenant accounts, and use synthetic records that make ownership and sensitivity obvious.
Combine documentation review, configuration inspection and controlled manual testing. Automated tools help discover coverage gaps, but business authorisation and workflow weaknesses require contextual tests. Capture requests and responses, identity claims, backend decisions and downstream state changes so each result is reproducible.
Evidence, remediation and retesting
A useful finding shows the required access, exact request or build condition, affected asset and business consequence. Avoid inflating severity from a tool label. Recommend the control closest to the trusted resource, name the remediation owner and specify how the fix will be verified.
Retesting should repeat the original case and adjacent variants, including other roles, objects, endpoints and content types. Add stable regression coverage to delivery pipelines or API integration suites. Monitor production denials and anomalies to detect both attacks and policy regressions after release.
Questions to ask a testing provider
- Will testers verify business-level authorisation and not only run scanners?
- How are accounts, test data and potentially disruptive cases controlled?
- Does the report include reproducible evidence, affected endpoints and remediation guidance?
- Are fixes retested across related variants?
- How are sensitive evidence and credentials protected and deleted?
Controls to verify
- Strict token validation with approved algorithms, issuer, audience and time claims.
- Short-lived credentials, tested revocation and protected refresh tokens.
- Server-side object and tenant checks at the data-owning service.
- Deny-by-default function and field policies.
- OAuth scopes bound to client, user, resource and consent.
- Unique least-privilege identities for services and automation.
- Idempotency and replay protection for consequential operations.
- Audit records linking identity, policy decision, object and outcome.
Common mistakes
- Treating a valid token as permission to every object.
- Testing only unauthenticated requests.
- Relying on API gateways while internal services trust arbitrary headers.
- Using one service credential across applications and environments.
- Checking only GET endpoints and ignoring writes, exports and bulk routes.
- Assuming UI restrictions protect direct API calls.
Related Detox resources
Use the API penetration testing service, cloud API checklist and LLM API checklist. The companion BOLA and IDOR guide focuses on object-level access.
Frequently asked questions
Is authentication testing enough for an API?
No. Most business data is accessed by authenticated users, so object, function, field and workflow authorization require separate negative testing.
Should authorization be enforced at the gateway?
A gateway can enforce coarse policy, but the service owning the resource should validate object and business context.
What accounts are needed?
At minimum use two same-role users in separate ownership contexts, two tenants where applicable and representative privileged roles.
Conclusion
API access control is reliable only when identity is strongly validated and every resource decision is enforced server-side. Build an explicit matrix, test negative paths and preserve regression cases for the endpoints that protect valuable data and actions.
Authoritative references
Building a repeatable API authentication and authorization testing programme
API authentication and authorization testing should be a managed capability rather than a one-time document. Define the systems in scope, accountable owners, test frequency and events that trigger reassessment. Connect results to the asset inventory, risk register and engineering workflow. Teams should agree what “complete” means: not simply that a tool finished, but that tokens, sessions, objects, fields, functions, workflows and service identities were exercised with valid evidence and unresolved gaps were recorded.
Create a small set of programme metrics that encourage risk reduction. Useful measures include coverage of high-value assets, percentage of tests with valid access, verified critical findings, time to remediation, recurrence and successful retest rate. Avoid rewarding raw alert volume. A rising finding count may reflect broader coverage, while a falling count may simply mean a scanner lost access.
Threat modelling and test-case design
Threat modelling makes the assessment specific to the business. Identify valuable data and actions, likely attacker positions, trust transitions and failure consequences. For api authentication and authorization testing, give particular attention to token acceptance, revocation, cross-tenant objects, privileged functions, delegated scopes and business-state transitions. Convert each threat into a positive case, a negative case and an abuse case, with expected evidence for each outcome.
Keep a traceable test catalogue. Record the requirement, precondition, identity, test data, action, expected decision and cleanup. Version the catalogue beside the architecture or service documentation. When an incident, product change or new technique appears, update the relevant cases rather than relying on individual tester memory.
Testing across the technology lifecycle
Apply lightweight checks during design and delivery, deeper validation before high-risk releases and periodic independent testing in production-like conditions. New components, permissions, providers, integrations and major configuration changes should trigger proportionate reassessment. The same control can behave differently in development and production because identity, network and data settings differ.
Coordinate with engineering and operations before testing. Establish communication channels, monitoring expectations and a rollback or stop procedure. Afterward, remove test accounts and synthetic records, revoke temporary access and confirm that evidence is retained only for the agreed period.
Prioritisation and remediation strategy
Prioritise a finding using demonstrated impact, exploitability, exposure, affected users and the reliability of compensating controls. A repeatable cross-tenant read or unauthorized consequential action should outweigh cosmetic token-hardening observations. Fix systemic causes before individual symptoms: strengthen a shared policy service, identity boundary or delivery control when several findings originate from the same design weakness.
Remediation guidance should be testable. Replace vague advice such as “improve security” with the enforcement point, required behaviour and a negative test that must pass. If an immediate fix is impossible, document temporary containment, monitoring, expiry and accountable risk acceptance.
