Skip to content

Feature 01: Use Cases for User Authentication & Session Management

Version Date Author Change Description
1.0 2025-09-04 Senior Business Analyst Initial Draft (Local Authentication)
2.0 2025-09-11 Senior Systems Analyst Rewritten for Google Directory SSO Integration

1.0 User Stories

  • US-01 (v2.0): As a user, I want to log in with my corporate Google account so that I can securely access the application without needing a separate password.
  • US-02 (v2.0): As a new user, I want my account to be automatically created the first time I log in with my corporate Google account so that I don't have to go through a manual registration process.
  • US-03 (v2.0): As an authenticated user, I want to log out of the application to end my session securely.

2.0 Use Case: User Login via Google SSO

This use case details the process of a user authenticating with the system using their corporate Google account.

  • Use Case ID: UC-01
  • User Story: US-01, US-02
  • Actors:
  • User (any employee with a valid corporate Google account)
  • System (the enterprise console application)
  • Google IdP (Google's Identity Platform)
  • Trigger: The user navigates to the application's login page and clicks the "Sign in with Google" button.

2.1 Main Success Scenario

  1. User clicks the "Sign in with Google" button on the application's login page.
  2. The System redirects the User's browser to the Google IdP for authentication.
  3. The User enters their corporate Google credentials (and any required MFA codes) into Google's interface.
  4. The Google IdP successfully authenticates the User.
  5. Google IdP redirects the User's browser back to the System's pre-configured callback URL, providing a temporary authorization code.
  6. The System's backend receives the authorization code. It contacts the Google IdP directly to exchange the code for an ID token and user profile information.
  7. The System inspects the returned user information and validates that the user's email domain matches the authorized corporate domain.
  8. The System checks its internal database for a user matching the unique Google ID.
  9. (JIT Provisioning): If no user exists, the System creates a new user record using the email and display name from the Google profile, setting the status to "Active" and assigning default roles.
  10. The System creates a new, secure application session for the user and sends a session token back to the User's browser in a secure cookie.
  11. The System redirects the User to the main application dashboard.
  12. Postconditions:
  13. The user is successfully authenticated within the application.
  14. A user record exists in the system for the user.
  15. The user has a valid application session.
  16. The user is viewing the application dashboard.

2.2 Alternative & Exception Flows

  • 2.2a: User Cancels Google Authentication
  • At step 3 of the main flow, the user decides to cancel the login process on Google's page.
  • Google IdP redirects the user back to the System's callback URL with an error indicator.
  • The System recognizes the cancellation and redirects the user back to the login page, displaying a message like "Login was canceled."
  • 2.2b: User Authenticates with a Non-Corporate Google Account
  • At step 3 of the main flow, the user successfully authenticates with a personal Google account (e.g., @gmail.com).
  • The flow proceeds to step 7.
  • The System inspects the user's email domain and finds that it does not match the authorized corporate domain.
  • The System rejects the authentication attempt, does not create a session, and redirects the user back to the login page with an error message: "Access denied. Please use a valid corporate account."
  • 2.2c: Authenticated User is "Inactive" in the System
  • The flow proceeds to step 8.
  • The System finds an existing user record, but their status is set to "Inactive" or "LockedOut".
  • The System rejects the authentication attempt, does not create a session, and redirects the user to the login page with an error message: "Your account is inactive. Please contact an administrator."

3.0 Use Case: User Logout

This use case describes the process of a user securely ending their application session.

  • Use Case ID: UC-02
  • User Story: US-03
  • Actors:
  • User (an authenticated user)
  • System
  • Trigger: The user clicks the "Logout" button within the application shell.

3.1 Main Success Scenario

  1. The user clicks the "Logout" button.
  2. The System receives the request and invalidates the user's current session on the server-side.
  3. The System instructs the user's browser to clear the session cookie.
  4. The System redirects the user to the public login page.
  5. Postconditions:
  6. The user's application session is terminated.
  7. The user can no longer access protected pages without re-authenticating.