Authentication

Authentication

Authentication

Documentation for sign-in, registration, and password recovery in the HRMS. These screens gate access to your organization workspace and tie each user to a tenant (company).

Overview

Authentication is organization-scoped: every account belongs to one company. New admins register with organization details, confirm identity via OTP, then sign in. Existing users log in with email and password or Google. Forgot password and reset password handle recovery without support tickets when email delivery works.

Screens in this module

| Screen | Purpose | | ------ | ------- | | Login | Email/password or Google for returning users. | | Register | Create organization + admin account; leads to OTP. | | Verify OTP | Six-digit code sent to the registrant’s email. | | Forgot password | Request a reset link by email. | | Reset password | Set a new password from the email link. |

Typical paths

  • New tenant — Register → Verify OTP → Login → HRMS home.
  • Returning user — Login (or Google) → HRMS home.
  • Lost password — Forgot password → email link → Reset password → Login.

Login

What it is: The default entry for users who already have an account on your tenant.

Fields and actions

  • Email address — Work email used at registration; must match an active user on the organization.
  • Password — Account password; masked input with optional show/hide toggle.
  • Sign in — Submits credentials; on success, the session starts and the user lands on the main app (dashboard or last route per product rules).
  • Forgot password? — Link to the forgot-password screen; does not sign the user in.
  • Continue with Google — OAuth sign-in when Google is enabled for the tenant; creates or links a user by verified Google email per your identity rules.

Divider

  • A visual or separates email/password from Google so users pick one primary method per attempt.

Footer

  • Create one (or equivalent) links to Register for users without an account.

Validation and errors

  • Empty email or password — inline message before submit.
  • Invalid credentials — generic message (do not reveal whether email exists).
  • Locked or disabled account — message directing the user to an administrator.
  • Google cancelled or failed — clear retry guidance without exposing provider internals.

Register

What it is: Onboarding flow for a new organization and its first admin user (not for inviting employees—that is a separate HR flow).

Fields

  • Organization name — Legal or display company name; becomes the tenant label in the HRMS.
  • Email address — Admin’s email; used for OTP, login, and transactional mail.
  • Password — Minimum strength per policy (length, complexity); confirm rules in UI copy if you collect confirmation on the same screen.

Actions

  • Create account (or Register) — Validates input, creates the pending organization/user record, sends OTP, and navigates to Verify OTP.
  • Continue with Google — Registers via Google when allowed: organization name may still be required before completion, or collected in a follow-up step per product design.

Footer

  • Link to Login for users who already have an account.

Notes

  • One registration flow per organization; additional users are invited inside the product, not via this public register screen.
  • Duplicate organization or email should surface a clear, actionable error (for example “Sign in instead” or “Contact support”).

Verify OTP

What it is: Email verification immediately after registration (and optionally after email change elsewhere in the product).

UI

  • Six single-digit inputs — One cell per digit; supports typing, backspace to previous cell, arrow keys, and paste of a full six-digit code from email or SMS.
  • Verify — Submits the code; on success, marks the email verified and routes to Login or auto-signs in per configuration.
  • Resend code — Sends a new OTP; enforce cooldown (for example 30–60 seconds) and daily caps to limit abuse.

Email content (operations)

  • OTP expires after a defined window (for example 10 minutes).
  • Email states organization name, code, and support contact if the user did not register.

Errors

  • Wrong or expired code — retry with remaining attempts if you implement lockout.
  • Too many resends — temporary block with support path.

Forgot password

What it is: Self-service start of password recovery when the user cannot sign in.

Fields and actions

  • Email address — Must match a user on the system; submit triggers a reset email if the address is recognized.
  • Send reset link — Always show neutral success copy (“If an account exists, we sent instructions”) to avoid email enumeration.
  • Back to login — Returns to the login screen without changing password.

Email

  • Contains a time-limited, single-use link to Reset password.
  • Link includes a token; invalid or expired tokens show an error with option to request a new email from forgot password.

Reset password

What it is: Completes recovery after the user opens the link from forgot-password email.

Fields

  • New password — Policy-compliant password; masked with show/hide.
  • Confirm password — Must match new password exactly.

Actions

  • Reset password — Saves the new hash, invalidates the reset token and active sessions if your policy requires re-login everywhere.
  • On success — redirect to Login with a short confirmation message.

Validation

  • Mismatch between password fields — inline error on confirm field.
  • Weak password — policy message before submit.
  • Expired or reused token — block submit and offer Forgot password again.

Google sign-in (login and register)

What it is: Shared OAuth button on Login and Register when Google identity is enabled.

Behavior

  • User chooses Google, consents on Google’s screen, and returns to the HRMS with an identity token.
  • Login — Match Google email to an existing user on the tenant; deny if no match unless you support domain-based auto-provisioning.
  • Register — Create user (and organization if applicable) from verified Google profile; still run Verify OTP or skip only if Google verification satisfies your compliance stance.

Operations

  • Configure OAuth client IDs per environment (development, staging, production).
  • Document which Google Workspace domains are allowed if you restrict by email domain.

Security and administration

  • Passwords stored with strong one-way hashing; never logged or returned in APIs.
  • Rate-limit login, OTP verify, and forgot-password endpoints.
  • Session timeout and “sign out everywhere” documented in admin settings when available.
  • Admins can disable users; disabled users cannot pass login or Google sign-in.
  • Audit sign-in failures and password resets for security review.
  • Introduction — HRMS modules and audience.
  • Schemas — users, organizations, and access-related tables for engineers.