Authentication and authorization answer different questions
Authentication checks an identity claim. A system uses an authenticator, such as a password, passkey, certificate, or one-time code, to evaluate that claim.
Authorization decides whether an identified actor may perform an action on a resource. The decision can use roles, permissions, ownership, tenant membership, attributes, relationships, or other business rules.
A successful sign-in does not prove that the user may open every account, invoice, or administration page. It establishes an identity context that later authorization decisions can use.
The distinction matters during testing because the failure evidence is different. An authentication defect can let someone impersonate a user. An authorization defect can give a valid user prohibited access.
Use the complete terms in test cases and defect reports. The abbreviations authn and authz can be useful in code, but they can confuse a wider delivery team.
Start with an explicit access model
Access testing becomes unreliable when the expected policy exists only in code or team memory. Ask the product owner and engineers to describe actors, resources, actions, and conditions.
Consider a subscription platform with customers, support agents, tenant administrators, and system administrators. Its resources include profiles, invoices, team invitations, billing settings, and audit records.
An access rule needs more detail than administrator can edit users. State which administrator, which user, which tenant, which fields, and which account states make the action valid.
Create a matrix with actors on one axis and resource actions on the other. Add conditions for ownership, tenant, status, time, data sensitivity, and step-up authentication where they apply.
Include anonymous and suspended actors. Include a user from another tenant. These negative identities often reveal missing rules that happy-path role checks do not exercise.
Test authentication as a complete lifecycle
A login form is only one part of authentication. Test registration, sign-in, multifactor challenges, recovery, credential changes, reauthentication, lockout behavior, and sign-out as connected workflows.
Begin with valid and invalid credentials, then vary one condition at a time. Check unknown accounts, disabled accounts, expired credentials, reused recovery links, delayed codes, and interrupted external-provider callbacks.
Observe more than the visible message. Capture the request, response, cookies, redirect chain, account state, notification, audit event, and any rate-control behavior that your environment permits you to assess.
Error messages should support recovery without exposing unnecessary account information. Compare the behavior for a known email address with the behavior for an unknown address.
Test sensitive account changes with the product policy in view. An authenticated session might still require recent authentication before a password, email address, payment method, or recovery factor changes.
Treat the session as a security boundary
HTTP requests are independent, so web applications use sessions or tokens to connect later requests with an authenticated identity. That connection makes session behavior part of authentication testing.
Record when the application creates the authenticated session. Check whether the identifier changes after sign-in, privilege elevation, password reset, or another security-sensitive transition.
Test idle expiry, absolute expiry, sign-out, password changes, account suspension, and administrator revocation. Verify both the browser result and a direct request that reuses the previous session value.
Use separate browser contexts or API clients for separate actors. Shared cookies, local storage, or token variables can create a false pass by sending the wrong identity with a request.
Do not place live credentials or tokens in screenshots, logs, source control, or defect attachments. Redact secrets while preserving claims, timestamps, identifiers, and response evidence needed for diagnosis.
Build authorization tests from actor, resource, and action
For each rule, identify the actor, resource, action, and expected decision. This structure works for a page, API endpoint, background operation, file, or field-level change.
Test a permitted case first to prove that the setup and action work. Then change only the authorization condition, such as the actor, tenant, ownership, role, scope, or resource state.
Cover read, create, update, delete, approve, export, invite, and administrative actions separately. Permission to view an invoice does not imply permission to edit, refund, download, or delete it.
Exercise the server directly where possible. Hiding a button can improve usability, but a missing button does not prove that the endpoint rejects the same action.
Check the denial side effects. A rejected request must not change data, send a message, enqueue work, disclose protected fields, or write a misleading successful audit event.
Test object, function, property, and tenant boundaries
Object-level authorization protects a specific record. A valid customer might open invoice 1042 but must not gain access to invoice 1043 by changing an identifier.
Use identifiers from controlled test accounts and authorized environments. Try another user in the same tenant, another tenant, a deleted owner, and an object in a restricted state.
Function-level authorization protects operations such as user export or role management. Send the administrative request with a standard user context, even when the normal interface does not show that operation.
Property-level authorization protects individual fields. A support agent might update a display name but must not assign an administrator role by adding a hidden property to the request body.
Tenant isolation applies across list, detail, search, export, notification, and background paths. A secure detail endpoint does not compensate for a list query that returns another tenant's records.
Understand API credentials, scopes, and HTTP evidence
An API can receive a cookie, API key, bearer token, client certificate, or another credential. Identify who or what the credential represents before you infer the expected access.
For a bearer token, inspect non-secret metadata and documented claims. Check issuer, audience, expiry, subject, scopes, roles, and tenant context according to the product's token contract.
A valid token can still lack permission for a resource. Test missing, malformed, expired, wrong-audience, insufficient-scope, wrong-tenant, and revoked credentials as distinct conditions.
HTTP status codes are useful evidence, but they are not the complete rule. RFC 9110 defines 401 for requests that lack valid authentication credentials and 403 for understood requests the server refuses.
Some systems return 404 to avoid revealing that a forbidden resource exists. Confirm the chosen contract, then verify that status, response shape, timing, logs, and side effects remain consistent.
Avoid weak tests that create false confidence
A test that checks only the login page cannot support a claim about authorization. A test that checks only role names can miss ownership, tenant, state, and field-level rules.
Do not rely on unpredictable identifiers as the access control. Random identifiers can reduce casual discovery, but the server still needs a permission decision for the requested object.
A single denied page request is also insufficient. Mobile clients, older API versions, export endpoints, GraphQL operations, file URLs, and background commands can reach the same protected data.
Be careful with cached responses and client-side state. Sign out one user, sign in as another, then check browser history, shared downloads, cached API responses, and restored tabs.
Test rule changes and revocation. Remove a role or tenant membership during an active session, then determine when the new decision should take effect across services and long-running operations.
Use a repeatable QA workflow
First, collect the identity and access policy, architecture boundaries, supported clients, and sensitive workflows. Mark unclear rules as product questions before creating expected results.
Second, prepare controlled actors and resources. Give every actor a known role, tenant, state, authentication method, and ownership relationship that another tester can reproduce.
Third, execute allowed and denied pairs. Keep the request constant while changing one access condition, and capture the decision plus all relevant side effects.
Fourth, automate stable high-risk rules as an authorization matrix. Run those checks in delivery pipelines when endpoints, policies, roles, or identity integrations change.
Finally, add focused exploratory work around recovery, concurrency, caching, stale sessions, unusual resource states, and service boundaries. These areas often need reasoning beyond a fixed matrix.
Report access defects with precise evidence
State whether the defect concerns authentication, session management, or authorization. Name the violated rule without putting sensitive data in the title.
Identify the actor, resource owner, tenant, action, relevant state, and expected decision. Include sanitized requests and responses, the resulting data change, and the evidence source for the policy.
Explain the realistic impact. Unauthorized reading affects confidentiality, unauthorized changes affect integrity, and blocked legitimate access affects availability or business operations.
Keep reproduction within authorized test accounts and environments. Stop and follow the security escalation process when the evidence could expose production data or affect another real user.
Authentication establishes the actor context. Authorization evaluates each protected action within that context. Strong QA work tests both decisions and the session that connects them.