Test Plan: User Authentication & Session Management¶

Version	Date	Author	Change Description
1.0	2025-09-11	Senior QA Lead	Initial Draft for local password authentication.
2.0	2025-09-11	Senior QA Lead	Complete rewrite to align with Google SSO integration.

1.0 Introduction¶

This document outlines the testing strategy for Feature 01: User Authentication and Session Management, revised for the new Google Single Sign-On (SSO) architecture. This feature's purpose is to provide a secure and seamless mechanism for users to authenticate via their corporate Google accounts, have their accounts automatically provisioned, and manage their application sessions.

This plan is based on the v2.0 requirements defined in:
- docs/features/01-user-authentication-and-session-management/index.md (BRD)
- docs/features/01-user-authentication-and-session-management/use_case.md (Use Cases)

2.0 Scope¶

2.1 In Scope¶

User authentication initiated by a "Sign in with Google" button.
The browser redirect flow to Google's authentication page and the callback to our application.
Just-In-Time (JIT) provisioning of a new user account on their first successful login.
Validation of the user's Google account to ensure it belongs to the authorized corporate domain.
Rejection of login attempts from non-corporate or personal Google accounts.
Rejection of login attempts for users who exist in the system but have an "Inactive" status.
Secure application session creation after a successful SSO callback.
User logout functionality and session termination.
Automatic session timeout due to inactivity.
API-level testing of the HandleGoogleAuthCallback gRPC endpoint.

2.2 Out of Scope¶

Local password management (all aspects are now obsolete).
Account lockout due to failed attempts (now managed by Google).
The user invitation flow (covered in Feature 06).
Performance and load testing of the authentication flow.

3.0 Test Strategy & Approach¶

Functional Testing: Manual UI tests will be conducted to verify the end-to-end SSO login journey, including all success and failure scenarios.
API Testing: Direct gRPC calls will be made to the AuthService to validate the backend logic for handling the Google callback and JIT provisioning.
Security Testing: Focus will be on ensuring the domain restriction is enforced and that sessions are managed securely.
Test Environments: QA, Staging.
Test Data: A set of specific Google accounts are required for testing:
- new_user@our-company.com: A valid corporate Google account that does not yet exist in our application's database.
- existing_user@our-company.com: A valid corporate Google account that already exists in our database with an "Active" status.
- inactive_user@our-company.com: A valid corporate Google account that exists in our database with an "Inactive" status.
- personal_user@gmail.com: A personal Google account not belonging to the corporate domain.

4.0 Test Environment Requirements¶

Backend & Gateway: The AuthService and API Gateway must be deployed with all Google SSO logic implemented.
Google OAuth 2.0 Credentials: The test environment must be configured with a valid Client ID and Client Secret from the Google Cloud Platform console.
Redirect URIs: The application's callback URLs must be correctly registered in the Google OAuth 2.0 client configuration.
Supported Browsers: Google Chrome, Mozilla Firefox, Microsoft Edge (latest stable versions).

5.0 Test Cases¶

Test Case ID	User Story	Description	Steps	Expected Result
TC-SSO-001	US-01, US-02	Happy Path: First-time login with a new corporate user (JIT Provisioning).	1. Navigate to the login page. 2. Click "Sign in with Google". 3. On the Google page, authenticate as `new_user@our-company.com`. 4. Grant consent if prompted.	The user is redirected back to the application and then to the main dashboard. A new user record is created in the database for `new_user@our-company.com`. A valid session is created.
TC-SSO-002	US-01	Happy Path: Login with an existing, active corporate user.	1. Navigate to the login page. 2. Click "Sign in with Google". 3. Authenticate as `existing_user@our-company.com`.	The user is redirected to the dashboard. No new user record is created. The `last_login_at` timestamp for the user is updated in the database. A valid session is created.
TC-SSO-003	US-01	Negative: Login attempt with a personal (non-corporate) Google account.	1. Navigate to the login page. 2. Click "Sign in with Google". 3. Authenticate as `personal_user@gmail.com`.	After the redirect from Google, the user is sent back to the login page. An error message is displayed, such as "Access denied. Please use a valid corporate account." No session is created.
TC-SSO-004	US-01	Negative: Login attempt by a user who is "Inactive" in the system.	1. Navigate to the login page. 2. Click "Sign in with Google". 3. Authenticate as `inactive_user@our-company.com`.	After the redirect from Google, the user is sent back to the login page. An error message is displayed, such as "Your account is inactive. Please contact an administrator." No session is created.
TC-SSO-005	US-01	Functional: User cancels the login process on Google's page.	1. Navigate to the login page. 2. Click "Sign in with Google". 3. On the Google authentication page, click "Back" or close the window instead of logging in.	The user is returned to the application's login page. No error messages are shown. No session is created.

5.2 Session Management¶

Test Case ID	User Story	Description	Steps	Expected Result
TC-SESS-001	US-03	Happy Path: Successful user logout.	1. Log in to the application via Google SSO. 2. Click the "Logout" button.	The user's session is terminated on the server. The user is redirected to the login page.
TC-SESS-002	US-03	Security: Attempt to access a protected page after logging out.	1. Log in and copy the URL of the dashboard. 2. Click "Logout". 3. Paste the dashboard URL into the address bar.	The application redirects the user to the login page. The dashboard content is not displayed.
TC-SESS-003	US-03	Functional: Verify session timeout due to inactivity.	1. Log in. 2. Leave the application idle for longer than the configured session timeout period. 3. Attempt to perform an action (e.g., click a navigation link).	The action fails. The user is automatically logged out and redirected to the login page, possibly with a message like "Your session has expired. Please sign in again."

6.0 UAT Scenarios¶

Scenario ID	User Story	Scenario Description	Acceptance Criteria
UAT-SSO-01	US-01	An employee needs to access the application for their work.	When I click the "Sign in with Google" button and log in with my company email, I am taken to the application dashboard.
UAT-SSO-02	US-02	A new employee is using the application for the very first time.	As a new employee, when I log in for the first time with my company Google account, the system lets me in without any manual setup.
UAT-SSO-03	US-01	An employee accidentally tries to log in with their personal Gmail account.	When I try to log in with my personal `@gmail.com` account, the system shows me an error and tells me to use my corporate account.
UAT-SESS-01	US-03	A user has finished their work and needs to securely exit the application.	When I click the logout button, my session ends, and I am returned to the login screen.

7.0 Entry & Exit Criteria¶

7.1 Entry Criteria¶

All development for the Google SSO integration is complete and deployed to the QA environment.
The environment is configured with valid Google OAuth 2.0 client credentials and redirect URIs.
All related unit tests are passing.

7.2 Exit Criteria¶

All test cases in this plan have been executed.
100% of Critical and High severity defects are closed.
UAT has been successfully completed and signed off by stakeholders.