Authentication and Authorization

Authentication and authorization are distinct concepts that are often confused. That confusion can lead QA to describe defects incorrectly and overlook real access risks.

→Authentication asks, “Who are you?”
→Authorization asks, “What are you allowed to do?”

Entering a username and password does not grant access to every resource or action. Conversely, some resources may be available without signing in, but only in a limited mode. Test these layers separately.

Authentication

Authentication confirms the identity of a user, service, or device. The system establishes whether the subject is who it claims to be.

→Username and password
→One-time code
→MFA
→SSO
→Access token or ID token
→Certificate
→Machine-to-machine credentials

Authentication extends beyond successful login into a lifecycle:

→A user or system presents a credential
→The server validates it
→A session is created or a token issued
→The credential has a lifetime
→It can expire, be revoked, become corrupted, or be used in the wrong context

Authentication checks therefore usually cover more than valid and invalid login attempts.

Authorization

Once the system identifies a subject, authorization determines which actions it permits.

→An ordinary user can view only their own orders
→A manager can view team orders
→An administrator can change user statuses
→An integration service can read data but cannot delete it
→An anonymous user can open a public page but not a personal account area

Authorization evaluates permissions, roles, policies, ownership, and business restrictions rather than identity.

A successfully authenticated user can still lack permission for an action. This is a separate access-control layer rather than a login error.

Why they are confused

Their failures can look similar from outside.

→The user is not signed in
→Their token has expired
→Their token is invalid
→They are signed in but lack the required role
→They have the role but are trying to open someone else's resource
→The backend checks access incorrectly

The UI may represent all of these as “access denied” or “sign in required.” QA must distinguish the defects, causes, and priorities.

Authentication checks for QA

→Valid credentials allow login
→Invalid credentials do not allow login
→Expired tokens and sessions are handled correctly
→Logout works correctly
→Logout invalidates the session as required
→Access does not persist longer than intended
→Remember me, refresh tokens, MFA, and SSO work correctly
→Credentials do not leak through URLs, local storage, logs, or network traces
→Repeated login across devices or tabs behaves correctly

Test the full credential lifecycle alongside the happy path. Many defects occur during renewal, expiration, revocation, and reuse of tokens or sessions rather than initial login.

Authorization checks for QA

→Users can see only permitted data
→Users can perform only permitted actions
→Access is enforced by the backend as well as the UI
→Direct IDs cannot expose another user's resources
→Roles do not have excessive permissions
→Hidden UI buttons cannot still be invoked through the API
→Rules are consistent across web, mobile, and API interfaces
→Role, status, or object-state changes do not accidentally grant permissions

Checking authorization only through the UI is a common trap. A hidden button does not establish protection. Effective authorization testing almost always includes direct API calls or at least inspection of backend responses.

Common failures

→Replacing an ID in a request exposes another user's data
→A previous user's token still works after logout
→A role change in the administration interface does not take effect promptly
→A service checks role but not object ownership
→The frontend displays forbidden while the backend executes the request
→An access token remains valid longer than expected
→Critical events do not revoke refresh tokens
→Anonymous users receive more data than allowed

These defects often matter more to product quality and security than ordinary UI issues.

Practical example

Consider an order system.

User A signs in and opens order #1001, then changes the ID in a network request or URL to #1002.

If the system returns another user's order, authentication has already succeeded. Authorization failed because the backend did not verify ownership.

This is a crucial QA check. Login and token issuance may work perfectly, yet weak resource access control still leaves the product vulnerable.

Key takeaways for QA

→Authentication and authorization are separate layers.
→Authentication checks identity; authorization checks access.
→Successful login does not permit every action.
→UI restrictions require backend enforcement to provide reliable protection.
→Access to another user's data and actions is an essential test area.
→Test token, session, and role lifecycles as carefully as login itself.

Role and ownership matrix for a local exercise

Separate identity from permission to access a particular object. In the local teaching fixture, record 1 belongs to user A and record 2 belongs to user B. A user can read their own record; an administrator can read either. The strings demo-user-a, demo-user-b and demo-admin are synthetic fixtures, not real credentials.

plain text

Identity	Request	Expected
No token	GET /records/1	401 and WWW-Authenticate
Unknown token	GET /records/1	401 and no record data
User A	GET /records/1	200, owner a
User A	GET /records/2	403, no owner or record fields
User B	GET /records/2	200, owner b
Administrator	GET /records/2	200, owner b
User A	POST /items with valid body	403 and no new item

For the forbidden-object case, check the response body as well as the status: an error code with another user’s data is still a failure. A 401 response concerns credentials; a 403 response means the operation is refused. A real product may use 404 to conceal object existence, so choose expectations from its contract. This fixture deliberately uses 403.

The fixture does not implement login, JWT verification, expiry, revocation or a session store. Test those mechanisms separately in an authorized environment; rejecting an arbitrary unknown string is not evidence that token expiry works.