authentication and registration - Domenicko/medical-booking-system GitHub Wiki

Authentication & Registration

1. Module Overview

The Authentication & Registration module is responsible for creating user accounts, authenticating users, and determining their roles and access permissions within the Medical Booking System.

The system includes three main user roles:

  • Patient — can search for doctors, view doctor profiles, and book and manage appointments.
  • Doctor — can manage their profile, availability, and appointments.
  • Admin — can manage users and perform administrative operations within the system.

The registration process includes input validation to ensure that the provided information is complete, valid, and unique where required.

Passwords must never be stored as plain text. They must be securely hashed before being stored in the database.

2. Patient Registration

Patient registration allows a new patient to create an account in the system.

Registration Form Fields

First Name

  • Type: String
  • Required: Yes
  • Validation: Minimum 2 characters.
  • The field must not be empty or contain only whitespace.

Last Name

  • Type: String
  • Required: Yes
  • Validation: Minimum 2 characters.
  • The field must not be empty or contain only whitespace.

Email

  • Type: String
  • Required: Yes
  • Validation: Must follow a valid email format.
  • The email must be unique in the system.

Phone Number

  • Type: String
  • Required: No
  • Validation: If provided, it must follow a valid phone number format.

Password

  • Type: String

  • Required: Yes

  • Validation:

    • Minimum 8 characters.
    • Must contain at least one number.
    • Must contain at least one special character.

Confirm Password

  • Type: String
  • Required: Yes
  • Validation: Must exactly match the password field.

User Role

  • Type: Enum
  • Required: Yes
  • Allowed value: patient

The user role should be assigned and validated by the backend. The frontend must not be trusted to determine or modify a user's permissions.

Patient Registration Business Logic

  1. The user opens the registration form.
  2. The user enters the required personal and account information.
  3. The system validates all required fields.
  4. The system validates the first name and last name.
  5. The system validates the email format.
  6. The system checks whether the email is already registered.
  7. The system validates the password requirements.
  8. The system checks whether the password and confirmation password match.
  9. If all validation rules pass, a new patient account is created.
  10. The password is securely hashed before being stored in the database.
  11. The new user is assigned the patient role.
  12. The user can then authenticate using their email and password.

Possible Registration Errors

The system should handle the following validation errors:

  • Required field is empty.
  • First name is shorter than 2 characters.
  • Last name is shorter than 2 characters.
  • Invalid email format.
  • Email is already registered.
  • Password is shorter than 8 characters.
  • Password does not contain a number.
  • Password does not contain a special character.
  • Password and confirmation password do not match.
  • Invalid phone number format.

3. Doctor Registration

Doctor registration requires additional professional information compared to patient registration.

Registration Form Fields

First Name

  • Type: String
  • Required: Yes
  • Validation: Minimum 2 characters.

Last Name

  • Type: String
  • Required: Yes
  • Validation: Minimum 2 characters.

Email

  • Type: String
  • Required: Yes
  • Validation: Must follow a valid email format and must be unique.

Phone Number

  • Type: String
  • Required: No
  • Validation: If provided, it must follow a valid phone number format.

Password

  • Type: String

  • Required: Yes

  • Validation:

    • Minimum 8 characters.
    • Must contain at least one number.
    • Must contain at least one special character.

Confirm Password

  • Type: String
  • Required: Yes
  • Validation: Must match the password exactly.

Specialty

  • Type: String
  • Required: Yes
  • Validation: Minimum 2 characters.

Examples include:

  • Cardiology
  • Dermatology
  • Neurology
  • Pediatrics

Medical License Number

  • Type: String
  • Required: Yes
  • Validation: Must be unique in the system.

Years of Experience

  • Type: Number
  • Required: No
  • Validation: Must be 0 or greater.

Clinic

  • Type: String
  • Required: No
  • Validation: If provided, it must contain a valid text value.

User Role

  • Type: Enum
  • Required: Yes
  • Allowed value: doctor

The role must be validated and assigned by the backend.

Doctor Registration Business Logic

  1. The doctor opens the registration form.
  2. The doctor provides personal and professional information.
  3. The system validates all required fields.
  4. The system validates the email format and checks its uniqueness.
  5. The system checks the uniqueness of the medical license number.
  6. The system validates the password requirements.
  7. The system verifies that the password and confirmation password match.
  8. If all validation rules pass, a doctor account is created.
  9. The password is securely hashed before being stored.
  10. The user is assigned the doctor role.
  11. The doctor account may initially be assigned a pending status.
  12. If required by the system, an administrator reviews and approves the doctor account.
  13. After approval, the doctor can access the appropriate doctor functionality.

Doctor Account Statuses

A doctor account can have the following statuses:

  • Pending — the account has been created but has not yet been approved.
  • Approved — the administrator has approved the doctor's account.
  • Active — the doctor can use the system normally.
  • Rejected — the doctor registration has not been approved.

The general status flow is:

Pending → Approved → Active
             ↓
          Rejected

4. Login / Authentication

The login functionality allows registered users to access their accounts.

Login Form Fields

Email

  • Type: String
  • Required: Yes
  • Validation: Must follow a valid email format.

Password

  • Type: String
  • Required: Yes
  • Validation: The field must not be empty.

Authentication Business Logic

  1. The user enters their email and password.
  2. The system validates the login form.
  3. The system searches for a user associated with the provided email.
  4. The system verifies the provided password against the stored password hash.
  5. If the credentials are incorrect, the system returns an authentication error.
  6. If the credentials are correct, the user is successfully authenticated.
  7. The system identifies the user's role.
  8. The user receives an authenticated session or authentication token.
  9. The user is redirected to the appropriate area of the application according to their role.

5. Role-Based Access

Different users have different permissions within the system.

Patient

A patient can:

  • View available doctors.
  • Search for doctors.
  • View doctor profiles.
  • View available appointment slots.
  • Create appointments.
  • View their own appointments.
  • Cancel their own appointments.
  • Manage their personal profile.

Doctor

A doctor can:

  • Manage their professional profile.
  • Manage their availability.
  • View their appointments.
  • Confirm or manage appointments according to the system rules.
  • View relevant patient information associated with their appointments.

Admin

An administrator can:

  • Manage users.
  • Manage doctor accounts.
  • Approve or reject doctor registrations.
  • Manage system-level data.
  • Perform administrative operations that are unavailable to regular users.

6. Authentication Security Rules

The Authentication module must follow basic security principles.

  • Passwords must never be stored as plain text.
  • Passwords must be securely hashed before being stored in the database.
  • Protected resources must require authentication.
  • Access to protected resources must be checked according to the user's role.
  • The backend must not trust the role value provided directly by the frontend.
  • Users must not be able to access another user's private information by modifying an ID in a request.
  • Authentication errors should not expose unnecessary information about whether a particular email address exists in the system.
  • Sensitive authentication information must not be exposed in frontend code or URLs.

7. General Validation Rules

The following validation principles apply to the Authentication & Registration module.

Required Fields

Required fields must not be:

  • Empty.
  • null.
  • undefined.
  • Made up only of whitespace characters.

String Fields

String fields such as names, specialties, and clinic names should be validated for:

  • Minimum length.
  • Maximum length where appropriate.
  • Empty or whitespace-only values.

Email

Email addresses must:

  • Be provided when required.
  • Follow a valid email format.
  • Be unique when creating a new account.

Password

Passwords must:

  • Contain at least 8 characters.
  • Contain at least one number.
  • Contain at least one special character.
  • Match the confirmation password during registration.

Phone Number

Phone numbers are optional for patients and doctors.

When provided, the value must follow the phone number format defined by the application.

8. User Data and Relationships

The authentication system provides the identity and role information used by other modules of the Medical Booking System.

The basic relationship is:

User
├── Patient
│   └── Appointments
│
├── Doctor
│   ├── Specialty
│   ├── Schedule
│   └── Appointments
│
└── Admin
    └── System Management

The authenticated user's identity and role will be used by other modules to determine which actions the user is allowed to perform.

For example, when a patient creates an appointment, the system should obtain the patient's identity from the authenticated session rather than allowing the patient to manually provide another patient's ID.

9. Expected Module Outcome

After successful implementation of this module:

  • New patients can create accounts.
  • New doctors can create accounts.
  • Users can authenticate using their credentials.
  • Each user has an appropriate role.
  • Required data is validated before account creation.
  • Duplicate email addresses are rejected.
  • Password requirements are enforced.
  • Passwords are stored securely.
  • Protected functionality is accessible only to authenticated users.
  • Role-based access rules prevent users from accessing functionality intended for other roles.