Cách thêm đăng nhập vào ứng dụng: mật khẩu, liên kết đăng nhập, Google và vai trò

Để thêm đăng nhập vào ứng dụng, hãy chọn một phương thức — email và mật khẩu, liên kết đăng nhập (liên kết đăng nhập một lần gửi qua email), hoặc "Đăng nhập bằng Google" — và triển khai bằng một thư viện xác thực đã được kiểm chứng hoặc nhà cung cấp được lưu trữ, thay vì tự viết từ đầu. Sau đó quyết định mỗi loại người dùng được làm gì (vai trò), và áp dụng điều đó trên máy chủ cho mọi trang và mọi yêu cầu API. Phiên phải dùng cookie an toàn, có thời hạn, và kết thúc đúng cách khi đăng xuất.

Hướng dẫn này đi qua từng lựa chọn và các chi tiết phân biệt một đăng nhập hoạt động với một đăng nhập an toàn. Về các khái niệm đằng sau, xem xác thực là gì.

Quyết định trước: bạn có cần đăng nhập không?

Đăng nhập làm tăng sự phiền toái và trách nhiệm. Bạn cần nó khi:

• Người dùng có dữ liệu riêng tư (đặt lịch, tài liệu, hóa đơn của họ)
• Người dùng có thể thay đổi những thứ người khác sẽ thấy
• Bạn thu phí để truy cập
• Những người khác nhau cần quyền khác nhau (chủ sở hữu, nhân viên, khách hàng)

Bạn không cần nó đối với một website giới thiệu, một danh bạ công khai, hay một biểu mẫu chỉ gửi email cho bạn. Danh sách chờ không cần tài khoản; một trường email là đủ.

Bốn phương thức đăng nhập phổ biến

Nhiều ứng dụng kết hợp hai cách: đăng nhập Google cộng với liên kết đăng nhập qua email là một cặp phổ biến, bao phủ được phần lớn người dùng mà không cần lưu bất kỳ mật khẩu nào.

Email và mật khẩu

Nếu bạn cung cấp mật khẩu, đây là những điều bắt buộc:

• Băm mật khẩu bằng thuật toán băm mật khẩu chậm. Hướng dẫn lưu trữ mật khẩu của OWASP khuyến nghị Argon2id, với scrypt, bcrypt hoặc PBKDF2 là lựa chọn thay thế. Không bao giờ lưu mật khẩu dạng văn bản thuần hay bằng một hàm băm nhanh thông thường.
• Đặt lại mật khẩu dùng một liên kết ngẫu nhiên, chỉ dùng một lần, có hạn, gửi tới email đã xác minh.
• Không tiết lộ email nào đã có tài khoản. "Nếu email này đã đăng ký, chúng tôi đã gửi liên kết đặt lại" tốt hơn "Không tìm thấy tài khoản".
• Giới hạn tần suất các lần đăng nhập và đặt lại để làm chậm việc đoán mật khẩu.
• Cho phép mật khẩu dài và trình quản lý mật khẩu; bỏ các quy tắc bắt buộc kiểu kết hợp ký tự lạ.

Liên kết đăng nhập và mã dùng một lần

Liên kết đăng nhập là một liên kết đăng nhập được gửi qua email cho người dùng. Bấm vào nó sẽ đăng nhập họ. Mã dùng một lần là cùng ý tưởng, nhưng người dùng gõ vào thay vì bấm.

• Liên kết và mã hết hạn nhanh và chỉ dùng được một lần.
• Liên kết nên đăng nhập người dùng trên thiết bị nơi họ bấm, và token không được nằm trong nhật ký hay công cụ analytics.
• Bạn cần dịch vụ gửi email đáng tin cậy — xem cách gửi email từ ứng dụng. Kiểm tra với Gmail và Outlook, và xem thư mục spam.

Đăng nhập bằng Google (và các nhà cung cấp OAuth khác)

"Đăng nhập bằng Google" dùng OAuth và OpenID Connect: Google xác nhận người dùng là ai và cho ứng dụng của bạn biết email và tên của họ. Cấu hình, tính đến tháng 9 năm 2026, được thực hiện trong mục Google Auth Platform của Google Cloud Console:

1. Tạo hoặc chọn một dự án, và điền trang Branding — những gì người dùng thấy trên màn hình đồng ý (tên ứng dụng, email hỗ trợ, logo).
2. Trên trang Clients, tạo một client loại "Web application".
3. Thêm authorized JavaScript origins và redirect URI — địa chỉ chính xác mà ứng dụng của bạn chạy và nơi Google đưa người dùng quay về sau khi đăng nhập.
4. Lưu client ID và client secret trong bí mật của ứng dụng.

Những việc thường gặp sai, theo tài liệu OAuth của Google:

• redirect_uri_mismatch: địa chỉ redirect phải khớp chính xác, kể cả http hay https, chữ hoa/thường và dấu gạch chéo cuối. Thêm một địa chỉ cho URL xem trước và một cho tên miền thật.
• Bắt buộc HTTPS: redirect URI phải dùng HTTPS, trừ localhost khi đang phát triển.
• Tham số state nên được kiểm tra khi quay về để chống giả mạo yêu cầu chéo trang (CSRF). Các thư viện tốt sẽ làm việc này cho bạn.

Nếu bạn chỉ yêu cầu thông tin đăng nhập cơ bản (tên, email, hồ sơ), Google cho biết xác minh ứng dụng không bắt buộc. Yêu cầu truy cập Gmail, Drive hoặc Lịch của người dùng là khác và cần xác minh.

Tự xây dựng hay dùng nhà cung cấp?

Hai lựa chọn đầu đều hợp lý. Nhà cung cấp được lưu trữ xử lý nhiều việc hơn nhưng thêm một phụ thuộc và đôi khi tính phí theo người dùng hoạt động; hãy kiểm tra giá hiện tại trên trang của họ. Thư viện giữ mọi thứ trong cơ sở dữ liệu của bạn nhưng để bạn tự cấu hình đúng nhiều hơn. Dù chọn cách nào, hãy nhờ AI dùng nó thay vì tự viết logic mật khẩu hay phiên.

Vai trò và quyền

Đăng nhập cho bạn biết ai là người dùng. Quyền quyết định họ được làm gì. Lúc đầu hãy giữ đơn giản:

Các quy tắc quan trọng hơn tên vai trò:

• Kiểm tra trên máy chủ, mọi lúc. Ẩn một nút trên trang không ngăn được ai đó gọi API trực tiếp.
• Phạm vi theo chủ sở hữu. Một thành viên lấy "lịch đặt 123" chỉ nên nhận được nó nếu đó là của họ.
• Người dùng không tự nâng quyền được. Bỏ qua các trường vai trò gửi từ trình duyệt khi cập nhật hồ sơ.
• Mặc định là không có quyền. Các route mới nên yêu cầu đăng nhập trừ khi bạn quyết định khác.

Kiểm tra bằng hai tài khoản: đăng nhập bằng một tài khoản, ghi lại ID của một bản ghi, rồi đăng nhập bằng tài khoản kia và thử mở nó. Danh sách kiểm tra bảo mật của chúng tôi có bài kiểm tra đầy đủ.

Bảo mật phiên

Sau khi đăng nhập, ứng dụng ghi nhớ người dùng bằng một phiên — thường là một cookie. Hướng dẫn quản lý phiên của OWASP khuyến nghị:

• Cookie phiên đặt Secure (chỉ HTTPS), HttpOnly (script trang không đọc được) và SameSite
• Cấp một ID phiên mới khi đăng nhập, và lại khi quyền thay đổi
• Hết hạn khi không hoạt động và thời hạn tối đa tuyệt đối, được thực thi trên máy chủ
• Đăng xuất kết thúc phiên trên máy chủ, không chỉ xóa cookie
• Phiên bị vô hiệu khi người dùng đổi mật khẩu

Lưu token đăng nhập trong local storage của trình duyệt là cách phổ biến trong các hướng dẫn, nhưng nó để lộ token cho mọi script chạy trên trang; cookie an toàn thường là lựa chọn mặc định tốt hơn cho ứng dụng web.

Một prompt bao quát các điều cốt lõi

Thêm tài khoản người dùng vào ứng dụng này. Người dùng có thể đăng ký và đăng nhập bằng email và mật khẩu, hoặc bằng Google. Dùng [thư viện hoặc nhà cung cấp] thay vì mã xác thực tự viết. Băm mật khẩu bằng Argon2id hoặc bcrypt. Thêm chức năng đặt lại mật khẩu qua email với liên kết một lần, hết hạn sau một giờ. Giữ phiên trong cookie an toàn, HttpOnly. Bảo vệ /dashboard và mọi route /api để chỉ người dùng đã đăng nhập mới dùng được, và đảm bảo người dùng chỉ thấy các dự án của chính họ. Thêm vai trò "admin" có thể xem tất cả người dùng; chỉ quản trị viên mới vào được /admin, được kiểm tra trên máy chủ.

Sau đó kiểm tra: đăng ký, đăng xuất, đăng nhập, đặt lại mật khẩu, thử một URL riêng tư khi chưa đăng nhập, và thử một bản ghi của người dùng khác.

Những lỗi thường gặp trong đăng nhập do AI xây dựng

• Bảo vệ chỉ nằm ở trang. Trang chuyển hướng người dùng chưa đăng nhập, nhưng API vẫn trả dữ liệu cho bất kỳ ai.
• Bí mật trong trình duyệt. Client secret của OAuth và khóa quản trị của nhà cung cấp xác thực phải nằm trên máy chủ.
• Nhầm lẫn URL xem trước và URL thật. Redirect URI của Google hoặc liên kết đặt lại trong email trỏ tới bản xem trước, nên đăng nhập bị lỗi sau khi xuất bản.
• Không xác minh email. Bất kỳ ai cũng có thể đăng ký làm anyone@company.com. Hãy xác minh email trước khi cấp quyền gắn với địa chỉ đó.
• Chỉ kiểm tra trường hợp thuận lợi. Hãy thử mật khẩu sai, liên kết hết hạn và một tài khoản thứ hai.

Thêm đăng nhập trong Mythex

Trên Mythex, đăng nhập cho người dùng ứng dụng của bạn là thứ bạn thêm vào ứng dụng — nó tách biệt với tài khoản Mythex của chính bạn. Mythex không cung cấp sản phẩm xác thực tích hợp sẵn, nên bạn mang theo một thư viện hoặc nhà cung cấp xác thực và khóa của họ:

1. Chọn một cách tiếp cận — ví dụ email và mật khẩu lưu trong cơ sở dữ liệu của riêng bạn, hoặc SDK của một nhà cung cấp được lưu trữ.
2. Nếu bạn tự lưu người dùng, ứng dụng cần một cơ sở dữ liệu; yêu cầu trong chat hoặc dùng /database.
3. Đặt khóa nhà cung cấp trong bí mật dự án (/secrets hoặc cài đặt dự án).
4. Dùng một prompt tương tự như trên, rồi kiểm tra trong Preview. Với đăng nhập Google, thêm redirect URI cho cả URL xem trước và địa chỉ đã xuất bản.

Xem Thêm đăng nhập vào ứng dụng trong tài liệu. Nếu bạn đang xây dựng một sản phẩm trả phí, cách xây dựng MVP SaaS đề cập đến tài khoản và thanh toán cùng lúc.

Câu hỏi thường gặp