Register - Account Management Strategy

Purpose

• Định nghĩa chiến lược thay đổi thông tin tài khoản cân bằng bảo mật và trải nghiệm.

Overview

• Secure & user-friendly: tăng cường xác thực theo rủi ro, có fallback; truyền thông rõ ràng; phù hợp mobile-first.

Core Principles

• Progressive verification: tăng dần mức xác thực theo risk level.
• Graceful degradation: có phương án fallback khi phương thức chính lỗi (VD: dùng OTP thay cho mật khẩu).
• Clear communication: giải thích rõ từng bước, trạng thái.

---

Re-Authentication Strategy (Identity Confirmation)

Trước khi thực hiện các thay đổi nhạy cảm (đổi email, đổi số điện thoại, thêm email phụ), hệ thống yêu cầu xác nhận danh tính người dùng đang thao tác.

Primary Rule

• Phương thức chính: Nhập Mật khẩu hiện tại. Nhanh chóng, ít ma sát cho người nhớ mật khẩu.
• Phương thức phụ (OTP Fallback): Nếu user quên/không có mật khẩu (ví dụ: login qua Google), cung cấp option Xác thực bằng OTP qua Email chính.

UX Guideline

• Tại UI “Xác nhận mật khẩu”, luôn có một nút phụ (text button): “Sử dụng mã OTP qua email”.
• Nếu user chọn OTP: Hệ thống gửi 6 chữ số OTP về Primary Email đã xác thực của tài khoản.
• Sau khi verify OTP thành công, quyền thao tác (elevation session) mở ra để đi tiếp vào bước 2.

---

Account Email Model

Finalized Approach

• Account được quản lý bằng user ID, không phải bằng email.
• Mỗi account có:
  • 1 primary email
  • 0..2 verified login emails bổ sung trong V1.
• Mọi verified email của account đều có thể dùng để đăng nhập.
• Primary email là email chuẩn cho:
  • hồ sơ tài khoản,
  • thông báo quan trọng,
  • liên hệ/support,
  • màn quản lý account.
• Phone contact là dữ liệu liên hệ riêng, không dùng làm login identifier trong active scope.
• Child account trong KID không dùng multi-email login; chỉ áp dụng sau khi account được nâng cấp sang login độc lập.

Product Rationale

• Giữ danh tính account ổn định theo user ID.
• Cho phép user đổi email chính mà không mất lịch sử học.
• Giảm friction khi user có nhiều email đang dùng thật tế.
• Tránh mô hình “nhiều email chính” gây mơ hồ cho recovery và support.

---

Email Change Strategy

Finalized Approach

3-Step Verification Process

1. Authentication:
   • nhập mật khẩu hiện tại HOẶC dùng OTP fallback qua email chính nếu account chưa có mật khẩu usable.
2. Current account verification:
   • OTP tới email hiện tại.
3. New email verification:
   • OTP tới email mới.

User Experience Flow

Password -> [Email hiện tại OTP] -> [Email mới OTP] -> Complete

Fallback Scenarios

• Không truy cập email hiện tại -> support/manual verification.
• Cả hai bước lỗi -> support/manual review.

Security Benefits

• Dual verification: cần mật khẩu + email ownership proof.
• Ownership mới: email mới bắt buộc verify.
• Sau khi đổi, user ID, tiến trình học và entitlement không thay đổi.
• Sau khi đổi thành công, gửi security alert về email chính cũ.

Primary Email Rule

• Đổi primary email không tạo account mới.
• Email cũ có thể được giữ lại như verified login email nếu user chưa xoá.

---

Add Login Email Strategy

Finalized Approach

2-Step Verification Process

1. Authentication:
   • nhập mật khẩu hiện tại HOẶC dùng OTP fallback qua email chính.
2. New email verification:
   • OTP tới email mới.

User Experience Flow

Password -> [Email mới OTP] -> Added as verified login email

UX Rules

• Chỉ thêm email nếu email đó chưa thuộc account khác.
• Email phụ chỉ trở thành login email sau khi verify thành công.
• Trong V1, giới hạn tối đa 2 email phụ.
• Không có khái niệm nhiều email chính.

Fallback Scenarios

• Email mới đã được dùng ở account khác -> chặn thêm, giải thích ngắn.
• User không truy cập được email mới -> không thêm alias, giữ nguyên account hiện tại.

---

Remove Login Email Strategy

Finalized Approach

• User có thể xoá email phụ đã verify.
• Không cho xoá nếu email đó là phương thức email cuối cùng còn lại để đăng nhập.
• Nếu user muốn bỏ email chính, phải đổi sang primary email khác trước.
• Bắt buộc Re-Authentication (Mật khẩu hoặc OTP Fallback) trước khi thực hiện gỡ mục đích tránh xóa do nhầm lẫn hoặc phiên trình duyệt bị chiếm quyền.

2-Step Verification Process

1. Authentication:
   • Nhập mật khẩu hiện tại HOẶC dùng mã OTP từ phương thức Fallback.
2. Confirm Delete:
   • Hệ thống tiến hành gỡ bỏ và thông báo email không thể login được nữa.

---

Phone Contact Change Strategy (Non-auth)

Finalized Approach

3-Step Verification Process

1. Authentication:
   • nhập mật khẩu hiện tại HOẶC dùng OTP fallback qua email chính.
2. Ownership check:
   • OTP tới email hiện tại.
3. Update phone contact:
   • nhập số điện thoại mới theo định dạng hợp lệ.

User Experience Flow

Password -> [Email OTP] -> [SĐT liên hệ mới] -> Complete

Fallback Scenarios

• Không nhận được OTP email -> resend/cooldown -> support.

Security Rationale

• SĐT là dữ liệu liên hệ CS, không phải login factor.
• Không yêu cầu verify phone trong active DOL English checkout/account baseline.
• Vẫn yêu cầu re-auth để tránh chỉnh sửa trái phép.
• Sau khi đổi thành công, gửi security alert về email chính cũ.

---

Social Account Management

Link Google Account

1. Đã đăng nhập DOL.
2. OAuth với Google.
3. Email check: tránh conflict.
4. Xác nhận liên kết.

Unlink Google Account

1. Đảm bảo tài khoản còn phương thức đăng nhập bằng email/password hoạt động.
2. Re-auth bằng mật khẩu.
3. Xác nhận; gửi thông báo.
4. Nếu account chỉ còn 1 email đăng nhập, không cho user tự đưa account về trạng thái khó recovery.

---

Security Implementation

Rate Limiting

• Email change: 1 lần/24h.
• Add/remove login email: 2 lần/24h.
• Phone contact update: 1 lần/7 ngày.
• Failed OTP: 5 lần + cooldown.

Audit Trail

• Log mọi thay đổi tài khoản.
• IP + device fingerprinting.
• Email thông báo cho mọi thay đổi.
• Rollback trong 7 ngày.

Emergency Safeguards

• Account freeze khi nghi ngờ.
• Support escalation (manual review).
• Identity verification: ID photo/video call khi cần.

Edge Cases

Switching Abuse Prevention

• Cooldown khi chờ OTP: disable gửi lại 60s, hiển thị countdown.
• Track riêng add/remove alias để tránh spam ownership checks.

Technical Issues Management

• Track số lần gửi lại; sau 5 lần thất bại -> thông báo bận + khoá nút 5 phút.

Multiple Failed OTP Strategy

• 5 lần fail + cooldown; escalation: 1m -> 5m -> 15m.

Email Ownership Conflict

• Một email chỉ thuộc đúng 1 account.
• Verified login email không được phép trùng với primary hoặc email phụ của account khác.

---

Mobile-First UX

Progress Indicators

• “Bước 1/3”, progress bar, time estimate.

Error Recovery

• Email lỗi: gợi ý kiểm tra spam + resend.
• Overload: “Quay lại sau 5 phút” + disable phù hợp.

Accessibility

• Văn bản rõ ràng; high contrast; voice guidance.

---

Technical Implementation

Session Management

• Elevation tạm thời cho thao tác nhạy cảm.
• Timeout 15 phút; re-auth cho thay đổi quan trọng.

Verification Tokens

• OTP 10 phút; secure links 30 phút single-use; RNG an toàn; SLA gửi OTP ~60s.

Database Design

• Bảng lịch sử thay đổi; bảng pending changes; tracking attempts; emergency contact.

Integration Points

• Email service (transactional, high deliverability); Support tickets; CRM sync cho phone contact.

---

Monitoring & Analytics

Success Metrics

• Change completion rate; time to complete; giảm ticket; ngăn chặn sự cố.
• Alias login success rate; tỉ lệ login nhầm thành signup phải thấp.

Alert Triggers

• Mẫu thay đổi bất thường; tỉ lệ lỗi cao; bất thường địa lý; thay đổi hàng loạt.

User Feedback Loop

• Survey sau thay đổi; điểm khó khăn; góp ý cải thiện.

References

• Rules - Register: .agent/rules/rule-register-login-ux.md
• Product standard: .agent/rules/rule-doc-standards.md
• Formatting & naming: .agent/rules/rule-doc-standards.md
• Glossary: docs/Command/CMD_Glossary.md

Change log

• 2026-03-16: Khóa policy email-only auth cho DOL English active scope; làm rõ đổi email/phone đều neo vào re-auth + OTP email hiện tại và phone không cần verify.
• 2026-03-06: Bổ sung mô hình 1 primary email + verified login emails và policy thêm/xoá email đăng nhập.