Skip to content

Authorization

Jump to bottom
Roman Kucher QA Nearn edited this page Sep 16, 2025 · 1 revision

📄 Authorization – User Stories & Requirements

1. Background & Problem Statement

The platform supports two login methods:

  • Google Authentication (OAuth 2.0)
  • Email OTP Login (6-digit temporary password sent to email)

Problems

  • Users may face confusion with different login flows.
  • Email OTP flow has time-based and validity constraints that must be clearly defined.
  • There is no password-based login, no “Forgot password,” and no “Remember me.”

2. User Stories

User

  • As a User, I want to log in using my Google account, so that I can authenticate quickly without creating a password.
  • As a User, I want to log in using a temporary OTP sent to my email, so that I can securely access the system without remembering a password.
  • As a User, I want clear error messages for invalid or expired OTPs, so that I can request a new one if needed.

System

  • As a System, I want to validate Google login tokens, so that only authenticated Google users can log in.
  • As a System, I want to generate secure OTP codes that expire after 30 minutes, so that authentication remains secure.
  • As a System, I want only the latest OTP to remain valid, so that multiple requests don’t compromise security.

3. Feature Scope

3.1 Google Auth Login Flow

  1. User selects “Continue with Google.”
  2. Redirects to Google OAuth 2.0 consent screen.
  3. User selects or enters Google account credentials.
  4. Upon success, Google returns token → system validates token → login succeeds.
  5. If authentication fails (canceled, invalid token, etc.), system shows error.

Validation Rules

  • Only valid Google accounts can log in.
  • Invalid or canceled login attempts return user-friendly errors.
  • Authentication session is created after token validation.

3.2 Email OTP Login Flow

  1. User enters email address.
  2. System generates 6-digit OTP and sends to email.
  3. User enters OTP in login form.
  4. If OTP is valid and within 30 minutes → login succeeds.
  5. If OTP is expired or invalid → error message displayed.
  6. Requesting a new OTP invalidates older codes.

Validation Rules

  • OTP length = 6 digits.
  • OTP validity = 30 minutes.
  • Only latest OTP remains valid.
  • OTP input accepts only numeric values.
  • Empty OTP field → validation error.

Error Handling

  • Invalid OTP → “Invalid code. Please try again.”
  • Expired OTP → “This code has expired. Request a new one.”
  • Unregistered email (if applicable) → “No account found with this email.”

4. Acceptance Criteria

4.1 Google Auth

  • AC1 – Successful Google login

    • Given a user is on the login screen
    • When the user clicks “Continue with Google” and successfully authenticates with Google
    • Then the system must create a valid session and log the user in.

  • AC2 – Canceled Google login

    • Given a user starts Google login
    • When the user cancels the Google authentication process
    • Then the system must display an error message and return the user to the login screen.

  • AC3 – Invalid token

    • Given Google returns an invalid or expired token
    • When the system validates the token
    • Then the system must reject the login and show a generic error message.

4.2 Email OTP

  • AC1 – Request OTP

    • Given a user is on the login screen
    • When the user enters a valid email and requests login
    • Then the system must send a 6-digit OTP to the user’s email and display a confirmation message.

  • AC2 – Successful OTP login

    • Given a user has received a valid OTP
    • When the user enters the OTP within 30 minutes
    • Then the system must create a valid session and log the user in.

  • AC3 – Expired OTP

    • Given a user has received an OTP that is older than 30 minutes
    • When the user enters the OTP in the login form
    • Then the system must reject it and display “This code has expired. Request a new one.”

  • AC4 – Invalid OTP

    • Given a user enters a wrong 6-digit code
    • When the OTP is submitted
    • Then the system must reject it and display “Invalid code. Please try again.”

  • AC5 – Reuse of OTP

    • Given a user has already used an OTP for successful login
    • When the same OTP is entered again
    • Then the system must reject it and prompt the user to request a new OTP.

  • AC6 – Multiple OTP requests

    • Given a user requests more than one OTP in a row
    • When the user attempts to log in
    • Then only the most recently issued OTP must be valid, and older OTPs must be invalidated.

  • AC7 – Input validation

    • Given the OTP field is empty or contains non-numeric characters
    • When the user submits the form
    • Then the system must display a validation error and not proceed.

5. Out of Scope

  • Password-based login, password recovery, and “Remember me.”
  • Multi-factor authentication (MFA).
  • Social logins beyond Google.

6. Non-Functional Requirements

  • Login must be consistent across web and mobile.
  • OTP delivery should occur within 5–15 seconds.
  • Both Google Auth and Email OTP must support backend + frontend validation.
  • Security: prevent brute force attempts (e.g., lockout after X failed OTP tries).
  • Error messages must be clear, consistent, and user-friendly.

Clone this wiki locally