Skip to content

Latest commit

 

History

History
109 lines (74 loc) · 9.31 KB

TEST_CASES.md

File metadata and controls

109 lines (74 loc) · 9.31 KB
Raw

Test Cases

These are the test cases used to make sure that the SuperTokens authentication features are working properly across the application. All of the details defined here should be possible with this app.

All Users

  • All users can visit pages/routes that don't require authentication, such as the following:
    • The home page (/)

Unauthenticated Users

  • Unauthenticated users cannot visit pages that require authentication, such as the /private page.
    • When an unauthenticated user visits a page requiring authentication, they will be redirected to the /login page. A successful login will return them to the page they were initially trying to visit (assuming they kept the same browser session without changing the URL).

Signup

  • Users can sign up on the /login page. Doing so will create a new account for them and redirect them to the home page.
  • A user who has an existing account cannot sign up again using the same email. They must login instead.
  • A user cannot create a new account unless their password is sufficiently secure. (You can adjust the security requirements if you want. We're only using the default requirements from SuperTokens.)

Logout

  • Authenticated users can logout of their account by visiting the /logout route. Doing so will clear their tokens and redirect them to the /login page.
    • When a user logs out, their session will be revoked. The same tokens for the session can no longer be used for authentication purposes.
      • Note: By default, access tokens provided by SuperTokens will still be usable until they expire even if the session was revoked. See Revoking a Session. For more aggressive behavior that immediately bans access tokens belonging to revoked sessions, see Access Token Blacklisting.

Signin/Login

  • Logging in with an existing account should start a new session for a user and redirect them to the home page.
  • Logging in with an invalid email-password combination should not work.
    • You can consider the following invalid email-password combinations:
      • A combination where the email does not correspond to an existing account.
      • A combination where the password does not correspond to the user having the provided email.

Authenticated Users

  • Authenticated users are allowed to visit (or make POST requests to) authenticated routes.
  • Authenticated users cannot visit the /login page (because they're already logged in). They will simply be redirected to the home page.
  • Authenticated users cannot visit the /reset-password page (because they've already proved that they know their password). They will simply be redirected to the home page.

Session Refreshing

  • If an authenticated user visits the /auth/session/refresh route with a valid access token and a valid refresh token, they will be given new auth tokens and get redirected to the home page.
  • If an authenticated user visits the /auth/session/refresh route with an expired access token and a valid refresh token, they will be given new auth tokens and get redirected to the home page.
  • If a user visits the /auth/session/refresh page with an expired access token and an invalid (OR expired) refresh token, their tokens will be removed and they will be redirected to the /login page.
    • You can consider the following to be invalid refresh tokens:
      • A refresh token that is stolen
        • For stolen refresh tokens, the corresponding session will be revoked, meaning that any users relying on this session will be logged out immediately.
      • A refresh token that has an invalid value (e.g., 1 or some other token value not recognized by the server)
      • A missing refresh token
  • If a user visits the /auth/session/refresh page without a valid access token, their tokens will be removed and they will be redirected to the /login page (even if they had a valid refresh token).
    • You can consider the following to be invalid access tokens:
      • An access token that has an invalid value (e.g., 1 or some other token value not recognized by the server)
      • A missing access token
  • If an unauthenticated user visits the /auth/session/refresh page, they will be redirected to the /login page.

Automated Session Refreshing

  • If an authenticated user visits an authenticated route with an expired access token, they will be redirected to the /auth/session/refresh route. (See Session Refreshing for what happens during that route visit.)
    • If session refreshing is successful, the authenticated user will be returned to the page that they were trying to visit (instead of the home page).
  • If an authenticated user attempts to submit a form to an authenticated route with an expired access token, they will be redirected to the /auth/session/refresh route. (See Session Refreshing for what happens during that route visit.)
    • If session refreshing is successful, the user's form submission will continue on the page that they were previously on.

Miscellaneous Auth Requirements

  • When a user visits (or otherwise interacts with) an authenticated route without a valid access token, their tokens will be removed and they will be redirected to the /login page -- even if they had a valid refresh token. (Note that expired access tokens are still considered "valid" and will result in the user being sent to the /auth/session/refresh page.)

Password Resets

  • When a user requests a reset password link ...
    • If there is no account associated with the provided email address, then no reset password link will be sent to that email address.
    • If there is an account associated with the provided email address, then a password reset link will be sent to that email address.
  • After a successful password reset, the user must login with their new password. The old password will no longer work.
  • A password reset will fail if the password is not sufficiently secure.
  • A password reset will fail if the password confirmation does not match the new password.
  • A password reset will fail if an invalid password reset link is used.
    • You can consider the following to be invalid reset password links:
      • Any link that uses an invalid password reset token (e.g., 1 or some other token value not recognized by the server).
      • Any link that attempts to use an expired password reset token.
        • A password reset token may be expired because it was already used or because too much time passed before it was used.
      • Any link with a missing password reset token. (That is, any link that doesn't have the token query parameter.)

Potential Approaches to Testing Different Scenarios

Reusing Old Tokens after a Logout

To test the scenario where a user attempts to use tokens that belong to a logged out session, simply update the server logic for the /logout route so that it doesn't update the user's cookies. This will cause the user's cookies to remain as they were after the logout (thereby leaving them with cookies belonging to a revoked session). Once their access token expires, the user should no longer be able to visit authenticated pages. (If you've configured the app to be more aggressive with access tokens, then the user should be blocked from authenticated routes immediately.)

Expired Access Token with Valid Refresh Token

Update the settings of your SuperTokens Core instance so that the access token expires more quickly.

Expired Access Token with Expired Refresh Token

Update the settings of your SuperTokens Core instance so that the access token and the refresh token expire more quickly.

Simulating a Stolen Refresh Token during a Session Refresh

This is pretty similar to the approach for Reusing Old Tokens after a Logout. You'll need to update the server logic for the /auth/session/refresh route so that it doesn't update the refresh token after a successful session refresh. This will leave the user with a new access token and the old refresh token. Visit the /auth/session/refresh route again. Now, a token theft should be detected, their session should be revoked, their cookies should be cleared, and they should be sent to the /login page. (Remember the caveat with access tokens mentioned earlier: Unless you configure the app to be more strict, an access token belonging to a revoked session will remain usable until it expires.)

Simulating an Action Requiring Authentication with a Missing Access Token and a Valid Refresh Token

Login to start a new user session. Next, delete the access token from the browser using the developer tools. Finally, attempt the action that requires authentication. The action should fail, the auth cookies should be cleared, and the user should be redirected to the /login page.

Automated Session Refreshing during Form Submissions

The form on the /private page was provided exactly for this test case. Simply use that.