~/qa-guides/login-and-authentication-testing-checklist

>_ Login and Authentication Testing Checklist

A practical login and authentication testing checklist for checking signup, login, logout, password reset, email verification, sessions, tokens, private pages, roles, permissions, account states, and auth emails.

LoginSessionsPassword resetPermissionsSecurity

Published Jun 3, 2026

Short answer

A Login and Authentication Testing Checklist is a list of checks for signup, login, logout, password reset, email verification, sessions, tokens, private pages, roles, permissions, and account security.

It helps make sure that a user can create an account, verify their email, log in, log out, reset their password, keep a session active, access only allowed pages, and avoid seeing someone else's data or restricted areas through direct URL access.

Authentication testing is especially important for SaaS products, web apps, mobile apps, internal tools, e-commerce accounts, customer portals, admin panels, dashboards, and any product with user accounts, private data, or role-based access.

The main idea is: authentication testing checks whether the right user can safely enter the product and access only what they are allowed to access.

This guide can also be used as an auth testing checklist, login testing checklist, password reset testing checklist, SaaS authentication QA checklist, or role-based access testing checklist for web products and customer portals.

Authentication Testing vs Authorization Testing

Authentication answers the question: who is this user?

It includes:

signup;
login;
logout;
password reset;
email verification;
session;
token;
remember me;
MFA / 2FA;
SSO or social login, if available.

Authorization answers the question: what is this user allowed to do?

It includes:

roles;
permissions;
private pages;
direct URL access;
admin access;
account-level access;
workspace or organization access;
read / write / manage permissions.

In simple terms: authentication checks access into the system, while authorization checks access inside the system.

This article includes both layers because login flow is almost always connected to private pages, roles, and permissions.

When to use a Login and Authentication Testing Checklist

Use this checklist whenever the product has accounts or any part of the authentication flow changes.

For example:

signup is added;
login page changes;
logout behavior changes;
email verification is added;
password reset changes;
password policy changes;
magic link is added;
MFA / 2FA is added;
Google, Apple, GitHub, or another social login is added;
SSO is added;
session duration changes;
token logic changes;
"remember me" changes;
private pages change;
roles or permissions change;
admin panel is added;
workspace or team access is added;
onboarding after signup changes;
there was a production bug related to login, session, or access;
there was a security-related incident.

For a small change, a short login smoke test may be enough. For a new SaaS product, customer portal, admin panel, SSO, MFA, or role-based access, it is better to go through the full authentication testing checklist.

Quick Login and Authentication Testing Checklist

If you need a minimal login smoke test, check that:

signup works, if available;
email verification works, if available;
login page opens;
user can log in with valid credentials;
invalid password shows a clear error;
user can log out;
private pages are unavailable without login;
direct URL does not open a private page without authentication;
session remains active after refresh;
expired session is handled clearly;
password reset email is sent;
reset link works;
old or expired reset link does not work;
user can change password;
old password no longer works after password change;
roles and permissions work for key users;
regular user cannot open admin page;
disabled or deleted account cannot log in;
login does not expose unnecessary information;
there are no critical console errors or failed API requests;
production login smoke check has passed after release.

This is not a full security audit. It is a minimal check that helps quickly confirm whether the authentication flow works at a basic level.

Login and Authentication Testing Checklist

1. Define the authentication scope

Before testing starts, it is important to understand which authentication scenarios exist in the product.

Check whether there is:

signup;
email verification;
email/password login;
phone number login;
magic link;
social login;
SSO;
MFA / 2FA;
password reset;
change password inside account settings;
logout;
remember me;
session expiration;
roles and permissions;
admin panel;
workspace, team, or organization access;
private pages that must be protected;
account states such as active, unverified, locked, disabled, or deleted.

The main question for this part is: which login, logout, access recovery, and access restriction scenarios need to be tested?

If the scope is not defined in advance, the team may check only happy path login and miss email verification, expired token, direct URL access, disabled account, or permissions.

2. Prepare test environment, users, and roles

Authentication testing requires prepared users and roles.

Check that:

test environment is available;
latest build has been deployed;
login page opens;
signup page opens, if available;
test email inbox is available;
users with different statuses are created;
active user is available;
unverified user is available, if email verification exists;
disabled user is available, if this account state is supported;
deleted user scenario is available, if needed;
locked user scenario is available, if account lockout exists;
admin user is available;
regular user is available;
user with limited permissions is available;
guest or unauthenticated scenario can be tested;
test password is known;
password reset can be safely tested.

Good test data preparation is especially important for roles, permissions, session expiration, account status, and password reset. Otherwise, authentication testing quickly turns into "I do not have the right account."

3. Check signup flow

Signup is the first authentication flow for a new user. If signup does not work, the product loses new users before onboarding even starts.

Check that:

signup page opens;
user can create an account with valid data;
required fields are actually required;
optional fields can be left empty;
email field is validated;
password field is validated;
password confirmation works, if available;
terms or consent checkbox works, if required;
duplicate email shows a clear error;
signup with an already registered email does not create a duplicate account;
signup creates a user in the system;
user gets the correct status after signup;
user lands on the correct page after signup;
onboarding starts, if expected;
signup does not automatically log in the user if email verification is required;
signup sends verification email, if needed.

Signup should be tested not only as a form, but also as the beginning of the account lifecycle: what was created, what status the user has, and what they can do next.

4. Check email verification

Email verification confirms that the user has access to the email address. It is important for signup, account security, and notifications.

Check that:

verification email is sent after signup;
email is sent to the correct address;
email has a clear subject;
verification link works;
user lands on the correct page after verification;
account status changes to verified;
verified user can log in;
unverified user is restricted according to product rules;
expired verification link shows a clear error;
already used verification link does not work again or is handled correctly;
user can request a new verification email;
repeated verification emails do not create confusion;
verification email does not contain staging links;
verification email does not contain test copy.

It is important to check that an unverified user cannot access parts of the product that should be available only after email verification.

5. Check login page

Check that:

login page opens;
email or username field is displayed;
password field is displayed;
login button is visible;
forgot password link works;
signup link works, if available;
social login buttons are displayed, if available;
SSO option is displayed, if available;
remember me checkbox is displayed, if available;
fields have clear labels;
password can be shown or hidden, if this feature exists;
layout is not broken;
login page works on mobile;
login page does not contain test copy;
login page does not link to staging or an old domain.

Login page is not just a form. It is the gate into the product, so the user should easily understand how to log in or recover access.

6. Check login with valid credentials

Basic happy path login should work reliably.

Check that:

active verified user can log in;
email/password works;
username/password works, if username is used;
login is case-insensitive for email, if expected;
password is case-sensitive;
leading and trailing spaces in email are handled correctly;
user lands on the correct page after login;
user lands on the intended page after login if they came from a protected URL;
session is created;
user sees their own data;
user does not see someone else's data;
login event is recorded in logs or analytics, if expected;
there are no unexpected redirects;
there are no critical console errors or failed API requests.

The main question is: can the correct user log in and land in the correct part of the product?

7. Check invalid login scenarios

Invalid login should be handled safely and clearly.

Check that:

wrong password shows a clear error;
unknown email shows a clear error;
empty email blocks submit;
empty password blocks submit;
invalid email format shows an error;
disabled account cannot log in;
deleted account cannot log in;
locked account cannot log in;
unverified account is restricted according to product rules;
repeated failed login attempts are handled;
error message does not expose unnecessary information, if this matters;
password field is cleared or preserved according to product logic;
user can try again;
form does not break after an error.

For security-sensitive products, it is often better not to reveal whether an email exists in the system. The exact error text depends on product and UX decisions.

8. Check logout

Logout should end the session and close access to private pages.

Check that:

user can log out;
logout button or menu item is available;
after logout, user lands on the correct page;
private pages are unavailable after logout;
browser back does not open private data after logout;
refresh after logout does not restore the session;
direct URL after logout leads to login or access denied;
logout works on mobile;
logout works after a long session;
logout from one tab is handled correctly in another tab, if important;
logout clears session according to product logic;
user can log in again after logout.

Logout is especially important for products with personal data, admin panels, shared devices, and business accounts.

9. Check session behavior

Session testing shows how the product behaves after login and during usage.

Check that:

session remains active after page refresh;
session remains active during navigation between pages;
session remains active when opening a new tab, if expected;
user stays logged in within expected session duration;
session expires after expected inactivity period;
expired session shows a clear message;
expired session redirects to login;
after login, user returns to the intended page, if expected;
autosave or entered data is not unexpectedly lost during session expiration, if this matters;
session does not last longer than intended;
session behavior is clear on both desktop and mobile.

Session expiration is a common source of poor UX. The user should not silently lose work because of an expired session.

10. Check expired token

Expired token or expired session should be handled predictably.

Check that:

expired token does not grant access to private API or page;
expired token shows a clear user-facing state;
expired token does not cause an endless loader;
expired token does not cause a redirect loop;
user is redirected to login, if needed;
user can log in again;
refresh token works, if used;
invalid refresh token is rejected;
expired refresh token is rejected;
old token does not work after logout, if expected;
token expiration does not expose a technical error to the user.

This section is especially important for SPAs, mobile apps, SaaS dashboards, and products with long-lived sessions.

11. Check remember me / keep me signed in

If there is a "Remember me" or "Keep me signed in" option, test it separately.

Check that:

checkbox is displayed;
user understands what remember me means;
checked state is saved;
user remains logged in longer if the option is enabled;
user does not remain logged in longer if the option is disabled;
logout disables the remembered session;
remembered session works after browser restart, if expected;
remembered session does not violate private/shared device policy, if restrictions exist;
remember me does not bypass MFA or security rules if they are required;
user can log out manually.

Remember me is convenient, but it should not break the product's security expectations.

12. Check password reset flow

Password reset is a critical authentication scenario. If it does not work, the user may lose access to their account.

Check that:

forgot password link opens;
user can enter email;
valid email accepts request;
invalid email format shows an error;
reset email is sent;
reset email is sent to the correct address;
reset email contains a working link;
reset link opens reset password page;
user can set a new password;
password confirmation works, if available;
password rules are applied;
successful reset shows a clear success state;
user can log in with the new password;
old password no longer works;
reset email does not contain staging links;
reset email does not contain test copy.

Password reset should be tested end-to-end: from requesting the reset email to successful login with the new password.

13. Check reset link security

Reset link should be limited by time and usage.

Check that:

reset link is one-time use, if expected;
already used reset link does not work again;
expired reset link does not work;
invalid reset token is rejected;
reset link for one user does not change another user's password;
reset token is not visible in unnecessary places;
reset token is no longer active after password change, if expected;
user sees a clear message for expired or invalid link;
user can request a new reset link;
repeated reset requests do not create confusion;
reset request does not reveal whether the email exists, if this is a security requirement.

Password reset is a sensitive flow. It should not be tested only through the happy path.

14. Check change password inside account

Change password is different from password reset: the user is already logged in and changes the password from account settings.

Check that:

change password page is available to logged-in user;
page is unavailable to unauthenticated user;
current password is required, if this is the product rule;
wrong current password is rejected;
new password validation works;
password confirmation works;
user cannot use current password as new password, if this is forbidden;
successful change shows confirmation;
user can log in with new password;
old password no longer works;
existing sessions remain active or end according to product logic;
user receives password change email notification, if expected.

For account security, it is important to understand what happens to other active sessions after password change.

15. Check password rules

Password rules should be strong enough for the product but clear to the user.

Check that:

minimum length works;
maximum length works;
letter requirement works, if used;
number requirement works, if used;
special character requirement works, if used;
common weak passwords are rejected, if this check exists;
password with spaces is handled according to rules;
password strength indicator works, if available;
password requirements are shown to the user;
error message explains which rule was violated;
valid strong password is accepted;
password rules work consistently in signup, reset password, and change password.

Password policy should not be a mystery. The user should understand which password they can use.

16. Check account lockout and brute-force protection

Account lockout and rate limiting protect login flow from too many login attempts.

Check that:

repeated failed login attempts are limited, if expected;
user sees a clear message after lockout;
lockout duration works;
user can unlock account according to product logic;
password reset works for locked account, if expected;
legitimate user is not blocked too aggressively;
rate limit is applied to login attempts;
rate limit is applied to password reset requests, if needed;
lockout does not expose unnecessary information;
logs record suspicious login attempts.

This section is especially important for SaaS, fintech, healthcare, admin panels, and products with sensitive data.

17. Check MFA / 2FA, if applicable

If the product supports MFA or 2FA, authentication testing should cover setup, login, and recovery scenarios.

Check that:

user can enable MFA;
QR code or setup key is displayed;
user can confirm MFA setup;
backup codes are created, if used;
user can log in with a valid MFA code;
invalid MFA code is rejected;
expired MFA code is rejected;
MFA step appears after password login;
user does not get access before successful MFA;
remember device works, if supported;
user can disable MFA according to rules;
recovery flow works if user loses device;
admin reset MFA works, if expected;
MFA errors are clear to the user.

MFA improves security, but it also adds the risk of locking users out. That is why recovery flow should be tested as carefully as the happy path.

18. Check social login, if applicable

Social login may use Google, Apple, GitHub, Microsoft, Facebook, or other providers. It often breaks because of redirects, callbacks, email matching, or account linking.

Check that:

social login button is displayed;
user is redirected to the correct provider;
user can successfully log in through provider;
callback returns user to the product;
new user is created, if expected;
existing user logs in to the existing account if email matches and this is expected;
account linking works, if supported;
denied provider permissions are handled clearly;
provider error is handled;
user does not land in the wrong account;
social login does not create a duplicate account without reason;
redirect does not lead to staging or an old domain;
logout behavior is clear for social login user.

Social login should be tested separately from email/password login because it has a different lifecycle and different failure scenarios.

19. Check SSO, if applicable

SSO is often used in B2B, enterprise SaaS, and internal tools. It is important to test not only login but also roles, domains, provisioning, and logout behavior.

Check that:

SSO button or enterprise login is available;
user can log in through identity provider;
user with allowed domain receives access;
user with disallowed domain does not receive access;
SSO callback works;
user attributes are passed correctly;
email, name, and organization are passed correctly;
role or group mapping works;
new user provisioning works, if used;
deprovisioned user loses access;
SSO session expiration is handled clearly;
SSO logout works according to rules;
SSO errors are clear;
fallback login works, if available.

For enterprise clients, SSO is often a blocker requirement. Even if regular login works, a release may not be accepted without correct SSO.

20. Check magic link or passwordless login, if applicable

Magic link and passwordless login simplify sign-in, but they depend on email delivery, token expiration, and link security.

Check that:

user can request magic link;
email is sent to the correct address;
magic link works;
user is logged in after opening the link;
expired magic link does not work;
already used magic link does not work again, if expected;
invalid token is rejected;
user can request a new link;
repeated requests do not create confusion;
magic link does not log in the wrong user;
link does not lead to staging or an old domain;
mobile email-to-browser flow works.

Magic link should be tested as a real user scenario: the user requests a link, opens email, and returns to the product.

21. Check private pages

Private pages should be available only to authenticated users.

Check that:

unauthenticated user cannot open dashboard;
unauthenticated user cannot open account settings;
unauthenticated user cannot open admin panel;
unauthenticated user cannot open user profile;
unauthenticated user cannot open order history;
unauthenticated user cannot open reports;
unauthenticated user is redirected to login;
after login, user returns to intended private page, if expected;
private page does not briefly flash sensitive content before redirect;
private data does not remain visible after logout;
private pages are not indexed by search engines, if important.

Private page testing should be done not only through navigation, but also through direct URL access.

22. Check direct URL access

Direct URL access is one of the most important authentication checks. A user can manually open a URL even if the UI does not show a link.

Check that:

unauthenticated user cannot open private URL;
user without permission cannot open restricted URL;
regular user cannot open admin URL;
user A cannot open resource URL of user B;
user from one organization cannot open resource from another organization;
deleted resource URL is handled correctly;
archived resource URL is handled according to rules;
direct URL after logout leads to login or access denied;
direct URL after session expiration is handled correctly;
API request to restricted resource is rejected too;
error page does not expose unnecessary private data.

Direct URL access often reveals authentication and authorization bugs that are not visible through normal UI clicks.

23. Check roles and permissions

Roles and permissions should be checked from both security and workflow perspectives.

Check that:

admin sees admin functionality;
regular user does not see admin functionality;
manager sees team data, if needed;
user sees only their own data;
viewer can view but not edit;
editor can edit but not manage users;
owner can manage settings, if expected;
guest does not see private data;
disabled user has no access;
permissions are applied in the UI;
permissions are applied on the backend;
buttons are hidden or disabled according to role;
direct API request cannot bypass permissions;
role change takes effect without unnecessary delay;
user does not keep old permissions after downgrade.

It is important to test not only "what the user sees," but also "what the user can do through a direct request."

24. Check organization, workspace, or tenant access

For SaaS and B2B products, there are often teams, workspaces, organizations, or tenants. The critical risk here is access to another organization's data.

Check that:

user sees only their own organizations;
user can switch between organizations, if supported;
user does not see data from another organization;
direct URL to another organization's resource is rejected;
API request to another organization's resource is rejected;
invite user works inside the correct organization;
role inside organization is applied correctly;
removed user loses access to the organization;
organization admin does not receive global admin access;
workspace switch does not preserve the wrong context;
reports and exports are limited to the current organization.

Multi-tenant access should be tested especially carefully. It is one of the highest-risk areas for SaaS products.

25. Check account states

An account may have different states, and each state should behave predictably.

Check accounts in statuses such as:

active;
unverified;
invited;
pending;
locked;
disabled;
suspended;
deleted;
archived;
expired trial;
canceled subscription.

Check that:

each account status has the correct access;
unverified user is restricted according to rules;
invited user can complete setup;
disabled user cannot log in;
suspended user sees a clear message;
deleted user cannot restore access unless recovery rules allow it;
expired trial user sees the correct paywall or message;
canceled subscription user gets the correct access;
account status is displayed in admin panel;
status change takes effect immediately or according to rules.

Account state bugs often appear after billing changes, admin actions, trial logic, and lifecycle automation.

26. Check account invitation flow

If the product supports user invitations, invite flow is also part of authentication testing.

Check that:

admin or owner can invite user;
invite email is sent;
invite email contains a working link;
invited user can create account;
invited user receives the correct role;
invite link is one-time use, if expected;
expired invite link does not work;
already accepted invite link does not work again or is handled correctly;
invite for existing user works according to product logic;
user cannot accept invite for the wrong email, if this is forbidden;
removed invite does not grant access;
invite does not add user to the wrong organization.

Invite flow is especially important for SaaS, B2B tools, admin panels, and collaboration products.

27. Check account settings and profile access

Account settings are often connected to email, password, profile, security settings, and connected accounts.

Check that:

account settings are available to logged-in user;
unauthenticated user cannot open settings;
user can update profile data;
user can change email, if supported;
email change requires verification, if this is the product rule;
user can change password;
user can manage MFA, if available;
user can manage social accounts, if available;
user can delete account, if supported;
user cannot open someone else's settings;
saved changes are displayed after refresh;
sensitive settings require re-authentication, if expected.

Account settings may look secondary, but issues here can affect user identity and account security.

28. Check re-authentication for sensitive actions

Some actions should require the user to enter their password again, complete MFA, or confirm identity.

Check that:

change password requires current password, if needed;
change email requires re-authentication, if needed;
delete account requires confirmation;
disabling MFA requires re-authentication, if needed;
viewing API keys requires confirmation, if this logic exists;
billing changes require re-authentication, if expected;
admin actions require confirmation if they are sensitive;
re-authentication window works;
failed re-authentication shows a clear error;
user cannot bypass re-authentication through direct request.

Re-authentication is especially important for SaaS, billing, admin panels, developer tools, and products with sensitive data.

29. Check authentication emails and notifications

Authentication flow often depends on emails and security notifications.

Check that:

signup verification email is delivered;
password reset email is delivered;
password changed email is delivered, if used;
email changed notification is delivered, if used;
login alert is delivered, if available;
suspicious login notification is delivered, if used;
invite email is delivered;
MFA recovery email is delivered, if available;
email is sent to the correct user;
links in email work;
links do not lead to staging or an old domain;
email does not contain test copy;
email does not expose unnecessary security data;
emails are not duplicated without reason.

Authentication emails must be reliable. Without them, the user may lose access or fail to understand what is happening with their account.

30. Check authentication UI, copy, and usability

Authentication flow should be understandable. The user should not have to guess what to do.

Check that:

login page is clear;
signup page is clear;
forgot password flow is easy to find;
error messages are written in human language;
success messages are clear;
password requirements are explained;
email verification instruction is clear;
account locked message is clear;
session expired message is clear;
CTA text matches the action;
user understands the next step;
empty states or blocked states explain what to do;
there are no internal comments or test copy;
auth pages work on mobile.

Authentication copy can strongly affect conversion and support load. A confusing reset password flow quickly becomes a support issue.

31. Check accessibility basics for authentication flows

Check that:

login form can be filled with keyboard;
signup form can be filled with keyboard;
tab order is logical;
focus state is visible;
fields have labels;
password field has a clear label;
error messages are connected to fields;
screen reader can understand errors;
color is not the only way to show an error;
submit button has a clear name;
social login buttons have accessible names;
MFA input is accessible;
password visibility toggle is accessible;
form is usable when zoomed in;
modal auth form can be closed with keyboard, if modal is used.

Accessibility is especially important for authentication because login is the gate to the entire product.

32. Check mobile authentication flow

Many users log in from a phone, especially through email links, magic links, social login, or password reset.

Check that:

login page opens on mobile;
signup page opens on mobile;
fields are easy to fill in;
keyboard does not cover the active field;
password manager works;
autofill works correctly;
submit button is visible;
error messages are visible;
email verification link opens on mobile;
password reset link opens on mobile;
social login redirect works on mobile;
MFA input works on mobile;
private page opens after login;
logout works on mobile;
there is no unexpected horizontal scroll.

Mobile authentication flow should be tested end-to-end: the user receives email, opens the link, returns to the product, and continues working.

33. Check browser compatibility

Authentication can break in different browsers because of cookies, storage, redirects, password managers, autofill, third-party providers, and security settings.

Check that:

login works in Chrome;
login works in Safari;
login works in Firefox, if supported;
login works in Edge, if supported;
mobile Safari works;
mobile Chrome works;
cookies work as expected;
password manager does not break login;
browser autofill does not break fields;
social login redirect works;
SSO redirect works;
password reset link works;
private pages open after login;
logout works;
there are no critical console errors.

Safari and mobile Safari are especially worth checking because sessions, cookies, redirects, and third-party authentication can behave differently there.

34. Check authentication security basics

Authentication testing does not replace a security audit, but basic security checks should be part of QA.

Check that:

login and signup work over HTTPS;
credentials are not sent in the URL;
password is not shown in plain text without user action;
password is not logged;
tokens are not visible in HTML;
secret keys are not visible in frontend;
session cookies have secure settings according to product rules;
sensitive pages require authentication;
permissions are checked on the backend;
CSRF protection works, if applicable;
brute-force protection works, if expected;
password reset token is time-limited;
reset token cannot be reused, if expected;
auth errors do not expose stack trace;
debug mode is not enabled in production.

This section does not replace penetration testing. But it helps catch basic authentication mistakes before release.

35. Check audit logs and monitoring

For authentication flow, it is important to see login issues, suspicious activity, and production errors.

Check that:

successful login event is logged, if needed;
failed login event is logged;
logout event is logged, if needed;
password reset request is logged, if needed;
password change is logged;
account lockout is logged;
MFA changes are logged, if available;
role changes are logged;
suspicious login attempts are visible;
auth errors appear in monitoring;
login error rate can be tracked;
spike in failed login attempts is visible;
support can find an auth issue by user or timestamp;
logs do not contain passwords or sensitive tokens.

Logs and monitoring help quickly understand whether a login problem is widespread or isolated to one user.

36. Check auth analytics, if important

Authentication analytics helps understand signup conversion, login failures, password reset problems, and onboarding drop-off.

Check that:

signup started event is sent, if used;
signup completed event is sent;
email verification completed event is sent, if important;
login success event is sent, if tracked;
login failure event is sent, if tracked;
password reset requested event is sent;
password reset completed event is sent;
events are not duplicated;
failed login is not counted as successful login;
UTM/source is preserved after signup, if needed;
analytics does not receive sensitive password or token data;
cookie consent does not unexpectedly break tracking.

Analytics should not interfere with authentication. But if the product tracks conversion funnel, authentication events should be correct.

37. Run production auth smoke after release

After changes in the authentication flow, run a short production check. Some issues appear only in production because of domain, cookies, email sender, SSO settings, OAuth redirect URLs, feature flags, or environment variables.

Check that:

production login page opens;
signup works, if enabled;
verification email is delivered, if needed;
login with valid credentials works;
private page opens after login;
logout works;
password reset email is delivered;
reset link leads to production domain;
password reset works;
roles and permissions work for critical user;
admin page is closed to regular user;
session remains active after refresh;
expired session does not cause a broken state;
SSO or social login works, if critical;
authentication emails do not contain staging links;
logs and monitoring do not show an increase in auth errors.

Production smoke check should be short and safe. Its goal is to make sure real users can log in, recover access, and open the right private pages after release.

Common mistakes

1. Testing only successful login

Successful login is only one scenario. Invalid password, expired session, logout, password reset, email verification, disabled account, private pages, and direct URL access should also be checked.

2. Not checking direct URL access

The UI may hide an admin page or private page, but a user can open the URL directly. Direct URL access must be tested for private pages, admin panels, and user-specific resources.

3. Confusing authentication and authorization

Login may work correctly, but permissions may be broken. A user may log in and gain access to someone else's data or admin functionality.

4. Not testing password reset end-to-end

It is not enough to check that the reset email was sent. You need to open the reset link, set a new password, log in with it, and confirm that the old password no longer works.

5. Not checking expired links and tokens

Verification links, reset links, magic links, and sessions should expire. An expired token should show a clear message, not a broken page.

6. Not testing logout

If a private page opens through browser back or direct URL after logout, that is a serious authentication issue.

7. Testing only admin user

Admin often sees everything and can do everything. Real problems often appear for regular users, managers, viewers, guests, or users with limited permissions.

8. Ignoring mobile authentication flow

Users often open verification emails or password reset links from a phone. Mobile authentication flow should be tested end-to-end.

9. Not checking authentication emails

Email verification, password reset, invite, and security emails are part of the authentication flow. If they do not arrive or link to staging, the user loses access.

10. Not running a production smoke check

Authentication may work on staging but fail in production because of cookies, domain, email sender, OAuth redirect URL, SSO settings, or feature flags.

FAQ

What is a Login and Authentication Testing Checklist?

A Login and Authentication Testing Checklist is a list of checks for signup, login, logout, password reset, email verification, sessions, tokens, private pages, roles, permissions, and account security.

It helps make sure users can safely log in, log out, recover access, and access only allowed pages and data.

What should be checked in authentication testing?

At minimum, check:

signup;
email verification;
login with valid credentials;
invalid login;
logout;
session behavior;
expired session or token;
password reset;
change password;
private pages;
direct URL access;
roles and permissions;
disabled or locked accounts;
authentication emails;
mobile authentication flow;
production auth smoke.

How is authentication testing different from authorization testing?

Authentication testing checks who the user is and whether they can enter the system.

Authorization testing checks what this user is allowed to do after login.

For example, login with the correct password is authentication. Checking that a regular user cannot open the admin page is authorization.

How do you test a login form?

A login form should be tested with positive and negative scenarios:

valid email/password;
wrong password;
unknown email;
empty email;
empty password;
invalid email format;
disabled account;
unverified account;
locked account;
remember me;
mobile login;
browser autofill;
error messages;
redirect after login.

After successful login, check that the user lands on the correct page and sees only their own data.

How do you test password reset?

Password reset should be tested end-to-end:

open forgot password;
request reset email;
receive email;
open reset link;
enter new password;
see success state;
log in with new password;
confirm old password no longer works.

Also check expired link, already used link, invalid token, and repeated reset requests.

How do you test email verification?

Email verification should be tested after signup:

verification email is delivered;
link works;
account becomes verified;
verified user can log in;
unverified user is restricted according to product rules;
expired verification link does not work;
user can request a new verification email;
email does not contain staging links.

How do you test session expiration?

Session expiration should be tested like this:

user logs in;
session remains active after refresh;
after expected inactivity, session expires;
private page is no longer available;
user sees a clear message;
user can log in again;
after login, user returns to the intended page, if expected;
expired session does not cause a redirect loop or endless loader.

What is direct URL access testing?

Direct URL access testing checks whether a user can open a private or restricted page directly through a URL.

For example:

unauthenticated user opens /dashboard;
regular user opens /admin;
user A opens /orders/user-b-order-id;
user from one organization opens a resource from another organization.

Correct behavior: access denied, redirect to login, or not found, depending on product rules. The user should not see someone else's data or restricted information.

Should roles and permissions be checked in authentication testing?

Yes. Login alone is not enough. After login, check that the user can see and do only what their role allows.

It is especially important to test admin, regular user, viewer, manager, guest, workspace user, and organization-level permissions if they exist.

How do you know authentication is ready for release?

Authentication can be considered ready for release when:

signup works;
email verification works;
login works;
invalid login is handled clearly;
logout closes private access;
password reset works end-to-end;
sessions and expired tokens are handled correctly;
private pages are protected;
direct URL access does not expose data;
roles and permissions work;
disabled, locked, or unverified accounts are handled correctly;
authentication emails are sent;
mobile authentication flow works;
there are no blocker or critical bugs;
production auth smoke check has passed.

Create a login and authentication testing checklist

Use this login and authentication testing checklist as a starting point for your next SaaS auth flow, customer portal, admin panel, signup flow, password reset flow, SSO integration, or role-based access release. In qa::checklist, you can organize checks by signup, login, sessions, password reset, private pages, direct URL access, roles, permissions, emails, security basics, and production readiness, then export the completed checklist to CSV.