When a user loses access, what still works?

An administrator removes someone from a team while that person still has the app open. Should the next request fail? What about an API token created before removal, or an invitation sent to the same address last week? A change to the membership record may leave those other paths open.

There is no single lifetime that fits every product. An integration may need a planned handoff. Whatever the rule, the server has to enforce it and administrators need to know what removal will revoke.

Use test accounts to invite a user, open a session, and issue an API credential if the product supports one. Try a read and a write action. Then remove the user or change their role and repeat those requests with the same session and credential. Test an unaccepted invitation separately. Record what the product was supposed to do and what it did.

Check account recovery as its own route back in. A reset link should not work twice. OWASP's forgot-password guidance calls for reset tokens to be linked to a user and invalidated after use. Its session guidance covers server-side invalidation and privilege changes.

• Specify when membership, sessions, invitations, reset links, and API credentials stop working.
• Apply those rules to requests from an already-open tab, not only to new sign-ins.
• If the product issues long-lived credentials, let administrators see and revoke them.
• Keep test accounts and organizations for repeating the checks after a change.

These are useful paths to include in web application testing. The preparation guide covers the test roles and boundaries to bring to a scoping call.