Define done

Create at least three non-production identities: an ordinary user, a privileged user, and an operator. The test is complete when every allowed transition works, every denied transition stays denied, notifications reveal no secrets, and an offboarded user cannot continue through an old session.

The OWASP Authentication Cheat Sheet and Forgot Password Cheat Sheet provide control considerations. They are not evidence that a particular identity product or configuration is correct.

Step 1: write the lifecycle matrix

Use these transitions:

  1. invite a new user;
  2. accept an invitation once;
  3. reject an expired or reused invitation;
  4. sign in and sign out;
  5. recover access without staff seeing a password;
  6. change a role and verify both gained and lost access;
  7. revoke existing sessions;
  8. suspend and reinstate an account;
  9. remove access to one tenant or business scope; and
  10. delete or deactivate according to retention policy.

For each row, record actor, prerequisites, expected access, expected notification, audit evidence, and rollback.

Step 2: test recovery as an attack surface

Recovery should not reveal whether an account exists more than the chosen policy allows. Recovery tokens should be single-use, expire, travel over a protected channel, and avoid changing the account until the flow completes.

Test an expired token, a reused token, repeated requests, an address change, and a recovery attempt after suspension. Confirm support staff have a safe escalation path that does not ask for or assign a reusable password.

Step 3: prove authorization changes

After a role downgrade, revisit direct URLs and repeat protected API actions. Hiding an interface control is not enough. Test that the server rejects access and that cached data is not left available to the old role.

For scope removal, sign in as a user who retains access to one client or workspace but loses another. Verify list results, search, files, exports, and identifiers cannot retrieve the removed scope.

Step 4: invalidate old sessions

Suspend the user while a session is active on two browsers. Define whether revocation must be immediate or bounded by a short session lifetime, then test the actual behavior. Repeat for password reset, role change, and complete offboarding.

Record any background tokens, API keys, device sessions, or integration credentials that require separate revocation.

Step 5: verify evidence and rollback

The operator should be able to identify who initiated each privileged change, which account and scope changed, when it happened, and the result. Avoid logging tokens, passwords, or excessive personal data.

Rollback does not always mean restoring access. An accidental role change may be reversed; a suspected compromise should remain contained until reviewed. Write that distinction beside each transition.

Compact verification

  • Every transition has a passing and denied case.
  • Recovery tokens expire and cannot be reused.
  • Role and scope losses are enforced by the server.
  • Old sessions obey the stated revocation policy.
  • Notifications and logs contain no credentials.
  • A named operator can repair an invitation or role mistake.

This exercise tests observable access behavior. It does not certify the application as secure or compliant.