Đăng nhập không mật khẩu bằng magic links: checklist UX và bảo mật

Magic link là gì, và điều gì có thể sai

Magic link là một liên kết đăng nhập dùng một lần gửi tới email của bạn. Thay vì gõ mật khẩu, bạn mở email, chạm vào liên kết và được đăng nhập.

Đây là lựa chọn phù hợp khi người dùng ghét mật khẩu, thường quên, hoặc chỉ đăng nhập thỉnh thoảng. Nó cũng giảm việc tái sử dụng mật khẩu giữa các trang, vì không còn mật khẩu để tái sử dụng. Nhưng điều đó không loại bỏ nhu cầu về bảo mật. Nó chỉ chuyển “chìa khóa” chính vào hộp thư email của người dùng.

Đó là sự đánh đổi cần làm rõ: đăng nhập không mật khẩu với magic links an toàn tới mức nào phụ thuộc vào tài khoản email của người dùng và khả năng giữ quyền truy cập riêng tư của họ. Nếu ai đó có thể đọc email của bạn, họ thường có thể đăng nhập thay bạn.

Dưới đây là những cách phổ biến khiến magic link gặp trục trặc trong thực tế:

• Quyền truy cập hộp thư bị đánh cắp (mật khẩu email bị lừa, SIM swap để khôi phục email, malware, hoặc máy tính chia sẻ để quên đăng xuất).
• Liên kết bị chuyển tiếp (cố ý hoặc vô ý) và người không đúng dùng nó.
• Người dùng mở email trên một thiết bị nhưng muốn phiên trên thiết bị khác, rồi bối rối khi app mở ở “nơi sai”.
• Thiết bị chia sẻ đăng nhập và giữ trạng thái đăng nhập, nên người kế tiếp có thể truy cập.
• Địa chỉ email gõ sai, liên kết đăng nhập tới người khác.

Một ví dụ nhỏ: ai đó yêu cầu liên kết trên laptop công ty, rồi kiểm tra email trên điện thoại cá nhân. Họ chạm vào liên kết, điện thoại đăng nhập, còn laptop vẫn hiện màn đăng nhập. Nếu luồng không giải thích điều này, sẽ có ticket hỗ trợ.

Nếu bạn xây tính năng này trong sản phẩm làm bằng AppMaster, hãy coi bước email là một hành động nhạy cảm, không chỉ là tiện lợi. Thông điệp rõ ràng, liên kết thời gian sống ngắn và điều khiển phiên đơn giản là những gì làm trải nghiệm an toàn.

Đăng nhập qua email không mật khẩu có phù hợp với sản phẩm của bạn không?

Đăng nhập không mật khẩu với magic links phù hợp nhất khi mục tiêu là truy cập nhanh, ít ma sát chứ không phải bảo vệ tối đa. Nó rất phù hợp cho sản phẩm mà người dùng đăng nhập không thường xuyên và ghét đặt lại mật khẩu, và nơi hộp thư email đã là “trung tâm” cho người dùng.

Một cách đơn giản để quyết định: nếu người lạ đăng nhập nhầm, thiệt hại thực tế tồi tệ nhất là gì? Nếu câu trả lời là “phiền toái nhưng có thể khắc phục”, magic links có thể là mặc định tốt.

Những trường hợp phù hợp thường gồm:

• Ứng dụng rủi ro thấp tới trung bình (công cụ nội bộ, bảng quản trị cho đội nhỏ, cổng khách hàng với quyền hạn giới hạn)
• Sản phẩm có người dùng thưa thớt và ghét reset mật khẩu
• Trải nghiệm “vào nhanh” như hỗ trợ, onboarding hoặc phê duyệt
• Sản phẩm giai đoạn đầu cần ít ticket hỗ trợ hơn

Hạn chế hoặc tránh dùng magic links là phương thức đăng nhập duy nhất khi:

• Tài khoản có giá trị cao (chuyển tiền, số dư lớn, hành động không thể hoàn lại)
• Bạn lưu trữ dữ liệu được quản lý hoặc nhạy cảm (sức khỏe, pháp lý, hồ sơ tài chính chi tiết)
• Người dùng thường chia sẻ hộp thư (mailbox chung, tài khoản quầy lễ tân)
• Khách hàng của bạn dễ bị nhắm mục tiêu (giám đốc, admin, vai trò đặc quyền cao)

Nếu sản phẩm có những khoảnh khắc nhạy cảm chứ không phải toàn bộ tài khoản nhạy cảm, dùng đăng nhập qua email để vào, rồi thêm yếu tố thứ hai hoặc kiểm tra nâng cao cho hành động rủi ro. Ví dụ: yêu cầu xác nhận thêm khi thay đổi thông tin thanh toán, xuất dữ liệu, hoặc thêm admin mới.

Cũng nên quyết định email được phép làm gì. Magic link "chỉ để đăng nhập" an toàn và dễ lý giải hơn. "Đăng nhập + khôi phục tài khoản" tiện lợi nhưng có nghĩa là ai có quyền truy cập email có thể chiếm đoạt tài khoản. Nếu bạn hỗ trợ thay đổi địa chỉ email, hãy coi đó là hành động rủi ro cao.

Nếu bạn xây app trong nền tảng no-code như AppMaster, quyết định này vẫn quan trọng: UI có thể đơn giản, nhưng chính sách về hành động nhạy cảm và khôi phục nên rõ ràng ngay từ đầu.

Luồng magic link cơ bản (và các quyết định bên trong)

Magic link có vẻ đơn giản với người dùng, nhưng có nhiều lựa chọn nhỏ ẩn phía sau. Một luồng rõ ràng giữ người dùng đi tiếp và giảm ticket hỗ trợ.

Luồng người dùng thấy

Hầu hết sản phẩm theo cùng một đường: người dùng nhập email, nhận tin nhắn, chạm liên kết và được đăng nhập.

Một cải tiến phổ biến là bước xác nhận cuối cùng sau khi liên kết mở. Thay vì đăng nhập ngay, bạn hiển thị một màn ngắn như “Xác nhận đăng nhập vào Acme” với một nút duy nhất. Điều này hữu ích khi ai đó chạm liên kết trên thiết bị sai hoặc email bị mở bằng công cụ xem trước.

Trên mobile, cần quyết định “chạm liên kết” nghĩa là gì. Nếu bạn có app native, trải nghiệm tốt nhất thường là: chạm liên kết -> mở app -> hoàn tất đăng nhập. Nếu app chưa cài, chuyển về web di động và sau đó gợi ý “Mở app” nếu cần.

Những quyết định bạn phải chốt

Trước khi xây đăng nhập không mật khẩu bằng magic links, khóa các quy tắc này để trải nghiệm dự đoán được:

• Nơi liên kết mở: in-app browser, trình duyệt hệ thống, hay trực tiếp trong app native (deep link).
• Có đăng nhập tự động hay yêu cầu màn xác nhận cuối.
• Làm gì nếu người dùng đã đăng nhập khi chạm liên kết.
• Điều gì xảy ra khi email thay đổi giữa chừng hoặc người dùng gõ email khác lần sau.
• “Thành công” trông như thế nào: về trang cuối, màn home mặc định, hay trang đã gây ra yêu cầu đăng nhập.

Đã đăng nhập là chi tiết dễ bị bỏ qua. Nếu người đã đăng nhập chạm liên kết mới, bạn có thể (a) giữ họ ở cùng tài khoản và hiện “Bạn đã đăng nhập”, hoặc (b) coi đó là chuyển tài khoản và hỏi xác nhận. Với app xây trên AppMaster (ví dụ cổng khách hàng hay công cụ nội bộ), lựa chọn (a) thường an toàn hơn trừ khi tính năng chuyển tài khoản thực sự cần thiết.

Quy tắc hết hạn: ngắn đủ để an toàn, dài đủ để hoạt động

Magic link chỉ giữ được cảm giác “không mật khẩu” nếu nó thật tiện lợi. Hết hạn là phần có thể âm thầm phá vỡ lời hứa đó. Quá ngắn, người dùng gặp liên kết hết hạn trong inbox và bỏ cuộc. Quá dài, liên kết chuyển tiếp hoặc bị lộ trở nên rủi ro hơn.

Mốc khởi điểm thực tiễn cho đăng nhập không mật khẩu với magic links là cửa sổ hết hạn từ 10 đến 30 phút. Cửa sổ ngắn hơn (3 đến 10 phút) phù hợp hành động rủi ro cao như đăng nhập vào khu vực admin hoặc phê duyệt thanh toán. Cửa sổ dài hơn (30 đến 60 phút) có thể dùng cho app rủi ro thấp, nhưng chỉ nếu bạn có điều khiển phiên mạnh và quản lý thiết bị tốt.

Hiển thị thời gian hết hạn rõ trong email và trên màn “Check your email”. Đừng giấu trong chữ nhỏ. Dùng câu đơn giản như “Liên kết này hết hạn sau 15 phút.” Nếu có thể, hiển thị đếm ngược trên màn chờ, nhưng đừng phụ thuộc vào đồng hồ thiết bị của người dùng để chính xác.

Độ trễ email và chênh lệch đồng hồ là chuyện thường gặp. Một số nhà cung cấp giữ tin trong vài phút, và một số người dùng mở email trên thiết bị khác. Một vài quy tắc giúp tránh nhầm lẫn:

• Dùng thời gian của server để tính hết hạn, không phải thời gian của người dùng.
• Nếu liên kết gần hết hạn, hiển thị thông báo rõ ràng như “Liên kết đã hết hạn. Yêu cầu liên kết mới.”
• Nếu liên kết còn hiệu lực nhưng đã được dùng, nói rõ điều đó (và cung cấp bước tiếp theo nhanh).

Khi liên kết hết hạn, trải nghiệm tốt nhất là cho phép gửi lại chỉ với một chạm từ trang đích. Giữ an toàn: chỉ cho gửi lại sau một thời gian cooldown ngắn, và tránh tiết lộ liệu email có tồn tại trong hệ thống hay không. Trang có thể nói “Nếu email này đã đăng ký, chúng tôi sẽ gửi liên kết mới.”

Một chi tiết nhỏ giảm ticket hỗ trợ: hiển thị chính xác địa chỉ email liên kết đã gửi tới (che một phần) trên màn chờ, kèm tuỳ chọn “Thay đổi email”. Nếu bạn dựng luồng trong công cụ no-code như AppMaster, thường chỉ vài trạng thái UI nhưng nó ngăn nhiều nhầm lẫn “tôi không nhận được email”.

Dùng một lần và quy tắc tái sử dụng (những phần người dùng thực sự tương tác)

Với hầu hết sản phẩm, mặc định là magic link dùng một lần. Nó bảo vệ người dùng khỏi những tai nạn phổ biến như chuyển tiếp email, hộp thư chia sẻ, hoặc ai đó mở lại tin nhắn cũ vài tuần sau. Nó cũng làm cho hỗ trợ đơn giản hơn: một khi liên kết được dùng, xong.

Vấn đề là xác định “đã dùng” nghĩa là gì trong thực tế. Người ta bấm hai lần, mở trên thiết bị sai, hoặc chạm liên kết trong chế độ xem trước email. Quy tắc của bạn phải an toàn nhưng cũng cảm thấy hợp lý.

Chuyện gì nên xảy ra khi cùng một liên kết mở hai lần?

Cơ sở tốt: lần đăng nhập thành công đầu tiên tiêu thụ token, và lần mở sau hiển thị thông báo rõ ràng như “Liên kết này đã được dùng. Yêu cầu liên kết mới.” Tránh lỗi mơ hồ. Nếu muốn giảm thất vọng, có thể cho một cửa sổ an toàn nhỏ trước khi đánh dấu là đã dùng, ví dụ: chỉ đánh dấu đã dùng sau khi session được tạo.

Một vài mẫu thân thiện với người dùng mà vẫn an toàn:

• Nếu liên kết mở lại trên cùng thiết bị và người dùng đã đăng nhập, chuyển họ vào app (và không hiển thị gì thêm).
• Nếu liên kết mở lại nhưng không có session đang hoạt động, hiển thị “Đã dùng hoặc đã hết hạn” kèm nút gửi liên kết mới.
• Nếu liên kết mở trên thiết bị khác sau khi đã dùng, coi nó là không hợp lệ và yêu cầu liên kết mới.

Nếu người dùng yêu cầu nhiều liên kết, các liên kết cũ có chết không?

Quyết định trước và nhất quán. Mặc định an toàn nhất là: mỗi yêu cầu mới vô hiệu hóa tất cả liên kết đang chờ trước đó. Điều này giới hạn thiệt hại nếu ai đó sau đó có quyền truy cập hộp thư.

Nếu bạn giữ nhiều liên kết cùng lúc hợp lệ, bạn cần bảo vệ mạnh hơn (hết hạn ngắn, dùng một lần nghiêm ngặt và điều khiển thiết bị rõ ràng). Nếu không, đăng nhập không mật khẩu với magic links có thể âm thầm biến thành khoá truy cập tồn tại lâu nằm trong email.

Tránh liên kết có thể tái sử dụng nhiều lần. Dù tiện lợi, nó đào tạo người dùng coi email như chìa khóa vĩnh viễn và làm việc chiếm đoạt tài khoản khó ngăn chặn.

Nếu bạn xây flow auth trong công cụ no-code như AppMaster, hãy viết những quy tắc này thành các trạng thái ngôn ngữ dễ hiểu (valid, used, expired, replaced) để thông điệp UI khớp với những gì backend thực thi.

Chi tiết UX giảm nhầm lẫn và ticket hỗ trợ

Hầu hết ticket hỗ trợ về magic links không phải lỗi bảo mật. Là các vấn đề như “Tôi không nhận được email”, “Tôi bấm mà không có gì xảy ra”, hoặc “Đây có phải phishing không?”. UX tốt ngăn cả ba loại này.

Sau khi người dùng gửi email, hiển thị màn “Check your email” riêng thay vì toast nhỏ. Làm cho nó bình tĩnh và cụ thể: cho biết gửi đến địa chỉ nào, làm gì tiếp theo và thử gì nếu không đến.

Một màn check-email mạnh thường bao gồm:

• Địa chỉ email chính xác đã dùng, kèm tuỳ chọn “Thay đổi email”
• Nút gửi lại với đếm ngược ngắn (để tránh người dùng click spam)
• Ghi chú về thời gian gửi điển hình (ví dụ “Thông thường đến trong 1 phút”)
• Nhắc nhẹ kiểm tra spam, tab promotions và bộ lọc công ty
• Một dòng ngắn về an toàn: “Đừng chuyển tiếp liên kết này”

Niềm tin được xây trong chính email. Dùng tên người gửi và tiêu đề nhất quán, giữ nội dung dự đoán được. Thêm một vài chi tiết giúp người dùng tin đó là hợp pháp, như “Yêu cầu từ Chrome trên Windows” hoặc “Yêu cầu lúc 15:42”. Tránh văn bản gây hoảng. Ngắn gọn là tốt: “Liên kết này đăng nhập bạn. Nếu bạn không yêu cầu, bỏ qua email.”

Cũng lập kế hoạch cho lỗi thường gặp nhất: email chậm hoặc bị lọc. UI không nên khiến người dùng bế tắc. Nếu liên kết có thể lâu, hướng dẫn người dùng làm gì trong khi chờ và đưa ra giải pháp dự phòng thân thiện.

Một giải pháp thực tế là kèm mã một lần ngắn trong cùng email với liên kết. Khi đó màn check-email có thể cung cấp “Nhập mã thay thế” cho trường hợp liên kết mở trên thiết bị sai hoặc bị chặn bởi bộ quét bảo mật email.

Một chi tiết nhỏ nhưng quan trọng: nếu người dùng bấm liên kết cũ hoặc đã dùng, hiển thị thông báo hữu ích và một bước tiếp theo rõ ràng như “Gửi liên kết mới cho tôi”, chứ không phải lỗi chung chung.

Những cơ bản về bảo mật phía sau (không cần thuật toán nặng)

Magic link an toàn tới mức token phía sau nó. Hãy coi token đó như chìa khóa tạm thời tới tài khoản: khó đoán, thời gian sống ngắn và chỉ dùng đúng mục đích.

Bắt đầu bằng tính không thể dự đoán. Tạo token dài, ngẫu nhiên (không dựa trên email, thời gian, hay ID tăng dần). Lưu trữ càng ít càng tốt. Mẫu phổ biến là lưu phiên bản băm của token (nếu database bị rò rỉ, liên kết thô không thể dùng lại) cùng metadata đủ để xác thực.

Ràng buộc token với ngữ cảnh có thể ngăn chuyển tiếp dễ dàng. Bạn không luôn muốn ràng buộc chặt (người dùng đổi thiết bị), nhưng có thể thêm kiểm tra nhẹ để bắt lạm dụng rõ rệt. Ví dụ: gắn token với email đã yêu cầu, và tuỳ chọn với fingerprint thô như họ user agent hay dải IP ban đầu. Nếu ngữ cảnh không khớp, bạn có thể yêu cầu liên kết mới thay vì chặn cứng.

Giới hạn tần suất quan trọng hơn toán học hoa mĩ. Không có nó, kẻ tấn công có thể spam form đăng nhập, làm phiền người dùng và dò xem email tồn tại hay không.

• Giới hạn yêu cầu theo email và theo IP (kể cả gửi lại)
• Thêm cooldown ngắn giữa các email (ví dụ 30-60 giây)
• Hiển thị cùng một thông điệp cho dù email có tồn tại hay không
• Cảnh báo khi có spike (nhiều email tới nhiều địa chỉ)

Cuối cùng, ghi log những gì bạn cần khi người dùng nói “Tôi không làm điều này.” Ghi lại sự kiện như đã yêu cầu liên kết, email đã gửi, liên kết mở, token chấp nhận/thất bại (và lý do), và session được tạo. Bao gồm timestamp, IP và user agent. Trong công cụ xây bằng AppMaster, những sự kiện này có thể được ghi như một phần business process đăng nhập để hỗ trợ và bảo mật có trail rõ ràng mà không phải mò server internals.

Quản lý thiết bị và phiên để người dùng hiểu được

Magic links loại bỏ mật khẩu, nhưng người dùng vẫn nghĩ theo thiết bị: “Tôi đã đăng nhập trên điện thoại” hay “Tôi dùng laptop chung”. Nếu bạn không cho họ cách đơn giản để xem và kết thúc phiên, ticket hỗ trợ sẽ tăng nhanh.

Bắt đầu với một quyết định: một tài khoản có bao nhiêu phiên đang hoạt động cùng lúc. Với hầu hết sản phẩm tiêu dùng, nhiều phiên là ổn (điện thoại + laptop). Với công cụ nhạy cảm (admin, tài chính, vận hành nội bộ), bạn có thể giới hạn hoặc yêu cầu liên kết mới khi xuất hiện thiết bị mới.

Một trang “Thiết bị” hoặc “Phiên đang hoạt động” nhỏ làm việc này dễ hiểu. Giữ đơn giản và hơi không chính xác còn hơn quá chi tiết. Một dòng thông tin tốt thường gồm:

• Tên thiết bị (hoặc trình duyệt và hệ điều hành nếu không phát hiện được model)
• Vùng địa lý gần đúng (thành phố hoặc khu vực, không địa chỉ đầy đủ)
• Thời gian hoạt động cuối
• Thời gian lần đầu thấy
• Nhãn ngắn như “Thiết bị này” cho phiên hiện tại

Từ đó, cho hai hành động rõ ràng. “Đăng xuất” chỉ kết thúc phiên đó. “Đăng xuất tất cả thiết bị” kết thúc mọi thứ, kể cả thiết bị hiện tại, và bắt buộc liên kết mới ở mọi nơi.

Giữa hai hành động, định nghĩa chuyện gì xảy ra khi mất thiết bị hoặc thiết bị chia sẻ. Mặc định an toàn là: đăng xuất sẽ vô hiệu hóa tất cả phiên hiện tại và mọi magic link chưa dùng. Người dùng không cần biết chi tiết; họ chỉ cần cam kết rằng quyền truy cập cũ đã hết.

Một tập hành vi đơn giản mà người dùng hiếm khi thấy ngạc nhiên:

• Đăng nhập bằng magic link tạo một phiên mới
• Mỗi phiên có timeout idle (ví dụ theo ngày) và tuổi tối đa (ví dụ theo tuần)
• Thay đổi email kích hoạt “đăng xuất tất cả thiết bị”
• “Đăng xuất tất cả thiết bị” cũng huỷ các liên kết chờ

Nếu bạn xây bằng AppMaster, bạn có thể mô hình hóa phiên trong Data Designer, hiển thị trong UI web/mobile cơ bản, và thêm hành động một nút trong Business Process. Người dùng có một view “phiên đang hoạt động” quen thuộc mà không cần bạn biến nó thành sách giáo khoa bảo mật.

Mối đe dọa và trường hợp cạnh: chuyển tiếp, email chia sẻ và gõ sai

Magic links có vẻ đơn giản, nhưng email lộn xộn. Người ta chuyển tiếp tin, chia sẻ hộp thư và gõ sai địa chỉ. Nếu bạn thiết kế chỉ cho trường hợp hoàn hảo, bạn sẽ gặp lockout khó hiểu và ticket hỗ trợ khó xử lý.

Chuyển tiếp là điều gây ngạc nhiên lớn nhất. Đăng nhập không mật khẩu với magic links nên giả định liên kết có thể được mở bởi người khác, trên thiết bị khác, vài phút hoặc vài giờ sau. Mặc định an toàn là dùng một lần kèm thông báo rõ “liên kết đã được dùng”, với nút yêu cầu mới. Nếu muốn bảo vệ thêm, hiển thị bước xác nhận nhẹ sau khi bấm khi thiết bị mới (ví dụ “Có phải bạn không?” và tuỳ chọn huỷ nhanh để thu hồi phiên).

Hộp thư chia sẻ cần quyết định sản phẩm, không phải bản vá kỹ thuật. Nếu nhiều người cùng đọc một email (như support@ hoặc sales@), magic link mặc định trở thành truy cập chia sẻ. Cân nhắc yêu cầu bước bổ sung cho tài khoản “team” (như mời tới email cá nhân) hoặc làm rõ trên UI rằng quyền truy cập email đồng nghĩa quyền truy cập tài khoản.

Gõ sai tạo ra “tài khoản ma” và vấn đề riêng tư. Tránh tự động tạo tài khoản mới khi lần đầu đăng nhập trừ khi sản phẩm thực sự cần. Cách an toàn hơn là xác nhận ý định trong app trước khi onboard, và giữ phản hồi email trung tính (cùng một thông điệp cho dù tài khoản có tồn tại hay không).

Aliases cũng quan trọng. Quyết định cách xử lý plus-addressing (name+tag@) và alias nhà cung cấp:

• Xử lý email như chuỗi chính xác (đơn giản hơn, ít bất ngờ)
• Hoặc chuẩn hoá mẫu phổ biến (ít tài khoản trùng lặp, nhưng rủi ro gộp người dùng không mong muốn)

Hỗ trợ là nơi mà mọi thứ có thể sai nhanh. Đừng yêu cầu người dùng chuyển tiếp email, dán token hoặc chia sẻ ảnh chụp màn hình chứa liên kết. Thay vào đó, cung cấp hành động trong sản phẩm như “gửi liên kết mới”, “đăng xuất các thiết bị khác”, và “báo rằng tôi không làm” để hỗ trợ giúp mà không chạm vào dữ liệu nhạy cảm.

Checklist nhanh trước khi ra mắt

Trước khi triển khai đăng nhập không mật khẩu với magic links, quyết định bạn muốn xử lý thế nào trong thế giới lộn xộn: email chậm, người bấm hai lần, và chuyển giữa điện thoại và laptop.

Bắt đầu với các quy tắc kiểm soát rủi ro và tải hỗ trợ. Nếu bạn làm sai những điều này, UI không cứu được.

• Đặt cửa sổ hết hạn rõ ràng (thường 10-20 phút) và hiển thị nó trong email và trên màn “Check your email”.
• Mặc định liên kết dùng một lần, và xác định “đã dùng” nghĩa là gì (sau click, sau khi session tạo thành công, hay sau lần mở đầu).
• Thêm giới hạn gửi lại và pacing (ví dụ cooldown ngắn), cùng thông điệp thân thiện giải thích tại sao họ không thể spam “gửi lại”.
• Giới hạn phiên đang hoạt động mỗi người khi cần, và quyết định chuyện xảy ra khi đạt giới hạn (giữ mới nhất, giữ cũ nhất, hoặc hỏi người dùng).
• Xử lý nhiều lần bấm và liên kết cũ một cách nhất quán: nếu liên kết hết hạn hoặc đã dùng, hiển thị trang đơn giản với một hành động chính (“Gửi liên kết mới”).

Tiếp theo, kiểm tra phần người dùng nhìn thấy. Hầu hết phàn nàn đến từ email không rõ ràng và hành vi mobile gây nhầm lẫn.

• Nội dung email: tên người gửi nhận diện được, tiêu đề rõ ràng, ngôn ngữ đơn giản, và dòng ngắn “Không yêu cầu? Làm thế nào” giải thích hành động.
• Hành vi mobile: xác nhận chuyện gì xảy ra nếu người dùng mở email trên thiết bị này nhưng muốn đăng nhập trên thiết bị khác, và liệu bạn hỗ trợ deep link vào app.
• Nhiều lần click: nếu người dùng bấm hai lần, tránh lỗi đáng sợ; nói rằng họ đã đăng nhập hoặc liên kết không còn hiệu lực.
• Quản lý thiết bị: cung cấp danh sách thiết bị đơn giản, tuỳ chọn “đăng xuất thiết bị này”, và ghi chú audit cơ bản (thời gian, thiết bị, vị trí nếu có).
• Khôi phục: có kế hoạch cho “Tôi không truy cập được email” (flow hỗ trợ, xác minh thay thế, hoặc quy trình thay đổi tài khoản an toàn).

Nếu bạn xây trong công cụ như AppMaster, ánh xạ từng mục checklist thành màn cụ thể và quy tắc business trong logic để hành vi nhất quán giữa web và mobile.

Ví dụ thực tế: đăng nhập thiết bị mới, liên kết hết hạn, và dọn dẹp

Maya làm support. Thứ Hai sáng cô ấy mở portal khách hàng trên laptop mới. Cô nhập email công việc và chạm “Gửi liên kết đăng nhập”. Email đến với magic link hết hạn sau 10 phút.

Cô bấm vào, trình duyệt mở và cô vào trong portal. Ở phía sau, liên kết được chấp nhận một lần, rồi đánh dấu là đã dùng. Portal tạo một phiên mới tên “Maya - Laptop Chrome” và giữ cô đăng nhập trong 14 ngày trừ khi cô đăng xuất.

Chiều cùng ngày, Maya thử đăng nhập từ điện thoại. Cô dùng lại email sáng và chạm cùng liên kết. App hiển thị thông báo rõ: “Liên kết đó đã được dùng. Yêu cầu liên kết mới.” Cô yêu cầu liên kết khác nhưng bị xao lãng. Sau 15 phút cô chạm vào và thấy: “Liên kết đã hết hạn. Gửi liên kết mới.” Cô yêu cầu lại, chạm ngay và phiên trên điện thoại tạo tên “Maya - iPhone Safari”.

Thứ Sáu, Maya giúp đồng nghiệp trên laptop chung. Cô đăng nhập, xong việc, vào “Thiết bị” và chạm “Đăng xuất thiết bị này”. Trước khi rời, cô cũng xoá phiên laptop chung khỏi tài khoản để không ai dùng lại.

Những quy tắc đơn giản app tuân theo:

• Liên kết hết hạn nhanh (phút), nhưng phiên có thể kéo dài (ngày)
• Mỗi liên kết chỉ dùng một lần; liên kết đã dùng hoặc hết hạn không thể tái sử dụng
• Mỗi lần đăng nhập tạo một phiên thiết bị có tên mà người dùng có thể xem
• Người dùng có thể đăng xuất một thiết bị hoặc thu hồi tất cả phiên nếu cần

Để xây luồng này trong AppMaster, bắt đầu với module xác thực và bật đăng nhập qua email. Lưu phiên vào database (user, tên thiết bị, thời gian tạo, thời gian sử dụng cuối). Dùng module messaging để gửi email đăng nhập, và một business process ngắn để xác thực trạng thái token (chưa dùng, chưa hết hạn), rồi tạo hoặc thu hồi phiên. Nếu muốn đăng nhập không mật khẩu với magic links mà không viết nhiều code, bạn có thể tạo các màn và logic trong visual editor và thử ngay.