Skip to main content

1. Overview

Scope In

  • Parent login via phone number + PIN
  • Teacher/Staff login via phone + PIN
  • Web Admin login via email + password
  • Session/device management
  • Logout for all roles
  • PIN setup for first-time parents

Scope Out

  • OAuth / Social login
  • Two-factor authentication (schema reserved, not active)
  • Password reset via OTP (available endpoint, not wired to SMS)

2. Requirements

Functional Requirements (FR)

What the module must DO — actions, behaviors, and outcomes.
  • SKOLE-AUTH-FR001: The module shall allow parents to authenticate using their registered mobile number and a PIN.
  • SKOLE-AUTH-FR002: The module shall match both father and mother phone numbers against parent_details.
  • SKOLE-AUTH-FR003: The module shall return all linked children’s profiles if the PIN matches.
  • SKOLE-AUTH-FR004: The module shall create a parent_devices record with device info and FCM token on login.
  • SKOLE-AUTH-FR005: The module shall generate and return a JWT containing sub, type, skole_id, phone, and session_token.
  • SKOLE-AUTH-FR006: The module shall allow teachers to authenticate with phone number and PIN against the staff table.
  • SKOLE-AUTH-FR007: The module shall create a staff_sessions record on teacher login.
  • SKOLE-AUTH-FR008: The module shall allow web admins to sign up with name, email, phone, and password.
  • SKOLE-AUTH-FR009: The module shall allow web admins to sign in with email and password.
  • SKOLE-AUTH-FR010: The module shall invalidate sessions on logout by marking the record as inactive (is_active = 0).
  • SKOLE-AUTH-FR011: The module shall allow updating device info (FCM token, platform, model) post-login.
  • SKOLE-AUTH-FR012: The module shall provide a PIN setup flow for first-time parent users.
  • SKOLE-AUTH-FR013: The module shall allow staff to set or edit passwords separately from the parent flow.

Non-Functional Requirements (NFR)

How well the module must do it — performance, security, and reliability.
  • SKOLE-AUTH-NFR001: The module shall perform authentication checks ensuring JWT tokens are short-lived and sessions expire after 30 days.
  • SKOLE-AUTH-NFR002: The module shall behave securely by ensuring session tokens are unique per device.
  • SKOLE-AUTH-NFR003: The module shall behave as a secure gateway by protecting all non-auth routes with a global JwtAuthGuard.
  • SKOLE-AUTH-NFR004: The module shall perform bypass logic for auth routes decorated with @Public().
  • SKOLE-AUTH-NFR005: The module shall support JWT extraction via Authorization header, query parameter, or cookie.

Constraints

Rules and boundaries — tech choices and platform restrictions.
  • C001: We must use PostgreSQL (via Prisma) for persisting users and sessions because it is the platform’s primary data store.
  • C002: We must use Firebase FCM for push notification registration to ensure cross-platform delivery.
  • C003: We must use standard JWT (jsonwebtoken) for token signing because the architecture requires stateless authentication.

3. Sub-modules / Backlog


4. Logical Implementation

Parent Authentication Flow

Teacher Authentication Flow

Web Admin Signin Flow

JWT Guard Strategy

All API routes are protected globally. The @Public() decorator (custom metadata key isPublic) bypasses the guard. JWT is extracted from:
  1. Authorization: Bearer <token> header
  2. ?access_token=<token> query parameter
  3. Cookie access_token

Error Handling


5. UI Requirements

Parent App — Auth Screens

Teacher App — Auth Screens

Web App — Auth Screen


UI Components

UI States


6. Conditional Expressions


7. Internal Module Connections


8. External Connections


9. Database Tables

Key Relationships

  • parent_devices.parent_idparent_details.id
  • parent_details.student_roll_no + parent_details.skole_idstudents.roll_no + students.skole_id
  • staff_sessions.staff_idstaff.id
  • user_sessions.user_idusers.id

10. API Endpoints Summary


  • Old devices can be logged out via separate endpoint

EP001: Parent Phone+PIN Login

Section 1: Endpoint Summary

Authenticates parent users using their registered phone number and PIN. Returns JWT token, parent profile, and all linked children for multi-child families.

Section 2: HTTP Details

  • HTTP Method: POST
  • Endpoint URL: /parent-app/parent-auth-verification
  • Content-Type: application/json
  • Authentication: Public (no token required)
  • Rate Limit: 5 requests per minute per IP

Section 3: Path Parameters

None required

Section 4: Query Parameters

None required

Section 5: Request Body Schema

Section 6: Response Schema (Success - 200)

Section 7: Error Responses

400 - Bad Request
401 - Invalid Phone
401 - Invalid PIN
429 - Rate Limited

Section 8: Implementation Examples

JavaScript (Node.js/React Native):
Python:
cURL:

Section 9: Database Context

Primary Table: parent_details
  • Primary Key: id (UUID)
  • School Isolation: skole_id
Query Flow:
  1. SELECT * FROM parent_details WHERE (father_phone = ? OR mother_phone = ?) AND skole_id = ?
  2. Verify: password.verify(pin, parent.pin_hash)
  3. SELECT * FROM students WHERE parent_id = ? AND status = ‘active’
  4. INSERT INTO parent_devices (parent_id, session_token, fcm_token, device_info, created_at)
Indexed Fields:
  • father_phone (for query performance)
  • mother_phone (for query performance)
  • skole_id (for school isolation)
  • session_token (for session lookup)
Data Retention: Keep parent_devices for 2 years, archive afterward

Section 10: Business Logic & Validations

Validation Rules:
  • phone_no: 10-15 digits, with or without country code, must exist in parent_details
  • pin: 4-6 digits, bcrypt hashed in database
  • skole_id: Must match user’s school
  • device_info: Optional but recommended
Authorization:
  • No prior authentication required (public endpoint)
  • After login, JWT validates on all subsequent requests
  • Parent can only access their own children and school data
Business Logic:
  1. Search for parent by father_phone or mother_phone
  2. If found, verify PIN against bcrypt hash
  3. If PIN matches, collect all active children linked to parent
  4. Generate unique session_token (UUID) with 30-day expiry
  5. Create parent_devices record for multi-device tracking
  6. Update FCM token for push notifications
  7. Sign JWT with parent type and return access_token
Special Behaviors:
  • PIN is never returned in response (masked as ****)
  • If parent has no PIN set, redirect to PIN setup flow
  • Multiple devices supported per parent (multi-login)
  • Old devices can be logged out via separate endpoint
  • PUT /parent-app/auth/device-info - Update device FCM token
  • POST /parent-app/logout - Logout and invalidate session
  • POST /web-app/parent-set-password - Setup PIN for first time
  • PATCH /web-app/parent-edit-password - Change existing PIN
  • GET /parent-app/student - Get children after login

Section 12: Response Summary Table


EP002: Parent Logout

Section 1: Endpoint Summary

Invalidates parent session by marking the device session as inactive, effectively logging out the parent from that specific device.

Section 2: HTTP Details

  • HTTP Method: POST
  • Endpoint URL: /parent-app/logout
  • Content-Type: application/json
  • Authentication: JWT Bearer Token (Required - Parent)
  • Rate Limit: Unlimited

Section 3: Path Parameters

None

Section 4: Query Parameters

Section 5: Request Body Schema

Section 6: Response Schema (Success - 200)

Section 7: Error Responses

401 - Unauthorized
404 - Session Not Found

Section 8: Implementation Examples

JavaScript:
Python:
cURL:

Section 9: Database Context

Tables Affected:
  • parent_devices - Mark is_active = 0
  • Query: UPDATE parent_devices SET is_active = 0 WHERE session_token = ? AND parent_id = ?
Behavior:
  • If logout_all_devices = false: Only invalidate current session_token
  • If logout_all_devices = true: Invalidate all session_tokens for the parent

Section 10: Business Logic & Validations

Validation:
  • JWT must be valid and not expired
  • Parent must have an active session
  • session_token must exist in parent_devices
Business Logic:
  1. Extract session_token from JWT
  2. Find parent_devices record where session_token matches
  3. Mark is_active = 0
  4. If logout_all_devices = true, also mark all other devices as inactive
  5. Return success message
  • POST /parent-app/parent-auth-verification - Login again
  • PUT /parent-app/auth/device-info - Manage device tokens
  • GET /parent-app/profile - Get parent profile after login

Section 12: Response Summary Table


EP003: Update Parent Device Info

Section 1: Endpoint Summary

Updates device information (FCM token, platform, model) for push notification delivery without requiring re-login.

Section 2: HTTP Details

  • HTTP Method: PUT
  • Endpoint URL: /parent-app/auth/device-info
  • Content-Type: application/json
  • Authentication: JWT Bearer Token (Required - Parent)
  • Rate Limit: 100 requests per minute

Section 3: Path Parameters

None

Section 4: Query Parameters

None

Section 5: Request Body Schema

Section 6: Response Schema (Success - 200)

Section 7: Error Responses

400 - Invalid FCM Token
401 - Unauthorized

Section 8: Implementation Examples

JavaScript:
Python:
cURL:

Section 9: Database Context

Table: parent_devices Update Query: UPDATE parent_devices SET fcm_token = ?, platform = ?, model = ?, os_version = ?, updated_at = NOW() WHERE session_token = ?

Section 10: Business Logic & Validations

Validation:
  • FCM token must be valid format
  • Platform must be one of: ios, android, web
  • JWT must be valid
Business Logic:
  1. Extract session_token from JWT
  2. Find parent_devices record
  3. Update fcm_token, platform, model, os_version
  4. Return updated device information
  • POST /parent-app/logout - Logout device
  • POST /parent-app/parent-auth-verification - Initial login

Section 12: Response Summary Table


12. Summary Table: All 13 Authentication Endpoints


EP004: Teacher Phone+PIN Login

Section 1: Endpoint Summary

Authenticates teacher/staff users using registered phone number and PIN. Returns JWT token and staff profile with assigned classes.

Section 2: HTTP Details

  • HTTP Method: POST
  • Endpoint URL: /teachers-app/teacher-auth-verification
  • Content-Type: application/json
  • Authentication: Public
  • Rate Limit: 5 requests per minute per IP

Section 5: Request Body Schema

Section 6: Response Schema (Success - 200)

Section 7: Error Responses

401 - Phone/PIN Invalid

Section 8: Implementation Examples

JavaScript:

Section 9: Database Context

Tables:
  • staff_details - Teacher/admin staff records
  • staff_class_assignments - Assigned classes
Indices:
  • phone_no (for lookup)
  • skole_id (for school isolation)

Section 10: Business Logic & Validations

Validation:
  • phone_no must exist in staff_details
  • pin must match bcrypt hash
  • Staff must be active status
  • Must belong to correct school (skole_id)
Business Logic:
  1. Find staff by phone_no and skole_id
  2. Verify PIN
  3. Load all assigned classes
  4. Generate JWT with staff role
  5. Create staff_devices session record
  6. Return token and profile
  • POST /teachers-app/logout - Logout
  • GET /teachers-app/classes - Get assigned classes
  • GET /teachers-app/students - Get students by class

Section 12: Response Summary Table


EP005: Teacher Logout

Section 1: Endpoint Summary

Invalidates teacher session, effectively logging them out from the app.

Section 2: HTTP Details

  • HTTP Method: POST
  • Endpoint URL: /teachers-app/logout
  • Authentication: JWT Bearer Token (Staff)

Section 5: Request Body Schema

Section 6: Response Schema (Success - 200)

Section 7: Error Responses

401 - Unauthorized

Section 8: Implementation Examples

JavaScript:

Section 9: Database Context

Tables:
  • staff_devices - Mark is_active = 0

Section 10: Business Logic & Validations

Mark session_token as inactive in staff_devices table.
  • POST /teachers-app/teacher-auth-verification - Login

Section 12: Response Summary Table


EP006: Admin Signup

Section 1: Endpoint Summary

Creates new admin account with email and password. First admin in a school requires special code/invitation.

Section 2: HTTP Details

  • HTTP Method: POST
  • Endpoint URL: /web-app/signup
  • Authentication: Public (with optional invitation code)

Section 5: Request Body Schema

Section 6: Response Schema (Success - 201)

Section 7: Error Responses

400 - Email Exists
400 - Weak Password
400 - Invalid Code

Section 8: Implementation Examples

JavaScript:

Section 9: Database Context

Tables:
  • users - Admin user records
  • schools - School codes validation
Password Hashing: bcrypt (12 rounds)

Section 10: Business Logic & Validations

Validation:
  • Email format valid and unique
  • Password strength check (8+ chars, uppercase, number, special char)
  • School code exists and valid
  • Invitation code not expired
Business Logic:
  1. Validate email uniqueness
  2. Check password strength
  3. If school_code provided, verify and create school + admin
  4. If invitation_code provided, verify it’s valid and not expired
  5. Hash password with bcrypt
  6. Create user and admin_role records
  7. Return confirmation
  • POST /web-app/signin - Login with created account
  • POST /web-app/reset-password - Password reset

Section 12: Response Summary Table


EP007: Admin Email+Password Login

Section 1: Endpoint Summary

Authenticates admin users using email and password. Returns JWT token with admin profile and school information.

Section 2: HTTP Details

  • HTTP Method: POST
  • Endpoint URL: /web-app/signin
  • Authentication: Public

Section 5: Request Body Schema

Section 6: Response Schema (Success - 200)

Section 7: Error Responses

401 - Invalid Credentials

Section 8: Implementation Examples

JavaScript:

Section 9: Database Context

Tables:
  • users - User records
  • admin_roles - Admin role assignments
  • schools - School details
Password Verification: bcrypt.compare()

Section 10: Business Logic & Validations

Validation:
  • Email exists in users table
  • Password matches bcrypt hash
  • User has admin role
  • Account not suspended
Business Logic:
  1. Find user by email
  2. Verify password
  3. Check if admin role exists
  4. Load school information
  5. Generate JWT (1 day expiry)
  6. If remember_me, generate refresh token (30 days)
  7. Return tokens and profile
  • POST /web-app/reset-password - Reset password
  • POST /web-app/logout - Logout
  • GET /web-app/profile - Get admin profile

Section 12: Response Summary Table


EP008: Request Password Reset

Section 1: Endpoint Summary

Sends password reset email link for admin accounts. Generates time-limited reset token (valid 1 hour).

Section 2: HTTP Details

  • HTTP Method: POST
  • Endpoint URL: /web-app/reset-password
  • Authentication: Public

Section 5: Request Body Schema

Section 6: Response Schema (Success - 200)

Section 7: Error Responses

404 - Email Not Found

Section 8: Implementation Examples

JavaScript:

Section 9: Database Context

Tables:
  • password_resets - Store reset token, email, expires_at
  • TTL: 1 hour, auto-cleanup for expired records

Section 10: Business Logic & Validations

Validation:
  • Email exists in users table
  • No active reset token for this email (or expired)
Business Logic:
  1. Find user by email
  2. Generate random reset token (32 chars)
  3. Save to password_resets with 1-hour expiry
  4. Send email with reset link
  5. Return confirmation (don’t expose token)
  • POST /web-app/confirm-reset - Verify token and set new password
  • POST /web-app/signin - Login

Section 12: Response Summary Table


EP009: Set Parent PIN (First Time)

Section 1: Endpoint Summary

Parents set their initial 4-digit PIN. Requires parent invitation/verification code from admin. Used during initial parent account activation.

Section 2: HTTP Details

  • HTTP Method: POST
  • Endpoint URL: /web-app/parent-set-password
  • Authentication: Public (with activation code)

Section 5: Request Body Schema

Section 6: Response Schema (Success - 200)

Section 7: Error Responses

400 - Invalid PIN Format
400 - PIN Mismatch
400 - Invalid Activation Code

Section 8: Implementation Examples

JavaScript:

Section 9: Database Context

Tables:
  • parent_details - Update pin_hash
  • parent_activations - Track activation codes (TTL: 7 days)

Section 10: Business Logic & Validations

Validation:
  • PIN format: 4-6 digits only
  • PIN matches confirm_pin
  • activation_code exists and not expired
  • parent_id matches activation code
  • Parent doesn’t already have a PIN set
Business Logic:
  1. Validate PIN format
  2. Verify activation_code for this parent_id
  3. Hash PIN with bcrypt
  4. Update parent_details with pin_hash
  5. Mark activation as completed
  6. Return success
  • POST /parent-app/parent-auth-verification - Login after PIN set
  • PATCH /web-app/parent-edit-password - Change PIN later

Section 12: Response Summary Table


EP010: Update Parent PIN

Section 1: Endpoint Summary

Parents change their existing PIN. Requires old PIN verification for security.

Section 2: HTTP Details

  • HTTP Method: PATCH
  • Endpoint URL: /web-app/parent-edit-password
  • Authentication: Public (with parent identification)

Section 5: Request Body Schema

Section 6: Response Schema (Success - 200)

Section 7: Error Responses

401 - Old PIN Incorrect

Section 8: Implementation Examples

JavaScript:

Section 9: Database Context

Tables:
  • parent_details - Update pin_hash, updated_at

Section 10: Business Logic & Validations

Verify old PIN, validate new PIN format, update in database.
  • POST /parent-app/parent-auth-verification - Login with new PIN
  • POST /web-app/parent-set-password - Initial setup

Section 12: Response Summary Table


EP011: Set Teacher PIN (First Time)

Section 1: Endpoint Summary

Teachers set their initial 4-digit PIN during account activation.

Section 2: HTTP Details

  • HTTP Method: POST
  • Endpoint URL: /web-app/staff-set-password
  • Authentication: Public (with activation code)

Section 5: Request Body Schema

Section 6: Response Schema (Success - 200)

Section 8: Implementation Examples

JavaScript:

Section 9: Database Context

Tables:
  • staff_details - Update pin_hash
  • staff_activations - Verify activation code

Section 12: Response Summary Table


EP012: Update Teacher PIN

Section 1: Endpoint Summary

Teachers change their existing PIN with old PIN verification.

Section 2: HTTP Details

  • HTTP Method: PATCH
  • Endpoint URL: /web-app/staff-edit-password
  • Authentication: Public

Section 5: Request Body Schema

Section 6: Response Schema (Success - 200)

Section 8: Implementation Examples

JavaScript:

Section 9: Database Context

Tables:
  • staff_details - Update pin_hash

Section 12: Response Summary Table


EP013: Admin Logout

Section 1: Endpoint Summary

Invalidates admin JWT token and ends the session.

Section 2: HTTP Details

  • HTTP Method: POST
  • Endpoint URL: /web-app/logout
  • Authentication: JWT Bearer Token (Required)

Section 5: Request Body Schema

Section 6: Response Schema (Success - 200)

Section 7: Error Responses

401 - Unauthorized

Section 8: Implementation Examples

JavaScript:

Section 9: Database Context

Tables:
  • sessions - Revoke session token or mark as inactive

Section 10: Business Logic & Validations

Extract and invalidate JWT session.
  • POST /web-app/signin - Login again

Section 12: Response Summary Table