Cách xây dựng ứng dụng di động cho pass số và thẻ truy cập

Làm rõ trường hợp sử dụng và chỉ số thành công

Trước khi bạn chọn QR hay NFC—hoặc Apple Wallet vs pass trong app—hãy xác định chính xác "digital pass" nghĩa là gì trong dự án của bạn. Một app có thể cấp thẻ truy cập nhân viên, thẻ hội viên, vé sự kiện, hoặc pass khách thời hạn, và mỗi loại có yêu cầu khác nhau về kiểm tra danh tính, thu hồi, và tần suất thay đổi credential.

Xác định loại pass (và quy trình thực tế)

Ghi lại các bước end-to-end, bao gồm ai phê duyệt và “thành công” ở cửa trông như thế nào.

Ví dụ:

• Thẻ truy cập: gắn với cá nhân; cần mở nhanh; thu hồi ngay khi offboard.
• Thẻ hội viên: ưu tiên dễ đăng ký và gia hạn hơn là kiểm soát truy cập nghiêm ngặt.
• Vé: quét lưu lượng lớn, chống sao chép, thời gian hiệu lực ngắn.
• Pass khách: do nhân viên bảo trợ; tự hết hạn; có thể hạn chế khu vực truy cập.

Xác định người dùng chính (không chỉ “end users”)

Liệt kê những người tương tác với hệ thống và mục tiêu của họ:

• Nhân viên/khách hàng/khách: cài đặt đơn giản, vào cửa tin cậy, ít rắc rối.
• Quản trị/nhân viên an ninh: cấp phát, thu hồi, kiểm toán, xử lý ngoại lệ (mất điện thoại, bị từ chối).
• Lễ tân/nhân viên sự kiện: xác minh nhanh và khắc phục sự cố khi đông.

Chọn chỉ số thành công có thể đo lường

Chọn các chỉ số phản ánh cả trải nghiệm người dùng và vận hành:

• Tỷ lệ kích hoạt: % người được mời thêm/kích hoạt pass thành công.
• Tỷ lệ mở cửa thành công: các lần mở/quét thành công ngay lần đầu.
• Thời gian cấp phát: từ yêu cầu/phê duyệt đến khi credential dùng được.
• Ticket hỗ trợ: khối lượng, nguyên nhân chính, và thời gian giải quyết.

Quyết định sớm về truy cập offline (và giới hạn của nó)

Nếu cửa hoặc đầu đọc phải hoạt động khi không có mạng, hãy định nghĩa truy cập offline hợp lệ trong bao lâu (phút, giờ, ngày) và chuyện gì xảy ra khi pass bị thu hồi trong lúc offline. Lựa chọn này ảnh hưởng tới thiết kế credential, cấu hình reader, và mô hình bảo mật của bạn sau này.

Chọn cách trình bày pass: QR, NFC và phương án dự phòng

"Digital pass" chỉ tốt khi nó được quét hoặc chạm. Trước khi xây giao diện, quyết định reader chấp nhận gì và người dùng có thể trình gì trong điều kiện thực tế (đám đông, kết nối kém, trời lạnh, đeo găng tay).

Các lựa chọn trình bày phổ biến (và điểm mạnh)

QR code là phổ quát và rẻ: bất kỳ đầu đọc camera—hoặc camera điện thoại để kiểm tra bằng mắt—đều có thể dùng. Chúng chậm hơn so với chạm và dễ sao chép hơn nếu dùng mã tĩnh.

NFC (chạm) giống như thay thế thẻ vật lý. Nhanh và quen thuộc, nhưng phụ thuộc vào đầu đọc tương thích và hỗ trợ thiết bị. Nó cũng có ràng buộc nền tảng (ví dụ có thể giả lập thẻ hay phải dùng credential qua Wallet).

Bluetooth (không chạm) có thể cải thiện khả năng tiếp cận và tốc độ, nhưng phức tạp hơn để tinh chỉnh (phạm vi, nhiễu) và có thể gây tình huống “tại sao nó không mở?”.

Link một lần / mã trong app (mã xoay, token ký) là fallback mạnh và giảm rủi ro sao chép. Chúng cần logic trong app và, tùy thiết kế, có thể cần kết nối mạng định kỳ.

Ánh xạ công nghệ tới ràng buộc của bạn

Khớp mỗi phương pháp với: phần cứng reader hiện có, throughput (người/phút), nhu cầu offline, ngân sách, và gánh nặng hỗ trợ. Ví dụ: turnstile đông người thường đòi hỏi tốc độ NFC; cổng tạm thời sự kiện có thể chịu được QR.

Chọn phương pháp chính và fallback rõ ràng

Một mô hình thực tế là NFC chính + QR làm dự phòng. NFC xử lý tốc độ; QR che cho điện thoại cũ, NFC hỏng, hoặc site không có NFC reader.

Lập kế hoạch cho các kịch bản "ngày tồi tệ"

Ghi rõ chuyện gì xảy ra khi:

• Điện thoại khóa: pass có thể trình từ màn hình khóa (Wallet) hay phải mở app?
• Không có mạng: credential có xác thực được offline (payload đã ký, entitlement cached) không, và trong bao lâu?
• Hết pin / điện thoại chết: có in QR tạm thời, override tại chỗ, hay thẻ vật lý dự phòng không?

Những quyết định này định hình tích hợp reader, tư thế bảo mật, và playbook hỗ trợ người dùng sau này.

Quyết định: In-app passes vs Apple Wallet và Google Wallet

Chọn nơi credential "nằm" là quyết định sớm vì nó ảnh hưởng tới tích hợp reader, trải nghiệm người dùng và giới hạn bảo mật.

Lựa chọn A: Pass trong app

Pass trong app do app bạn hiển thị và quản lý. Điều này cho bạn toàn quyền với UI, xác thực, phân tích và luồng tùy chỉnh.

Ưu điểm: branding đầy đủ và màn hình tùy biến, xác thực linh hoạt (sinh trắc học, step-up), ngữ cảnh phong phú (sơ đồ site, hướng dẫn), và dễ hỗ trợ nhiều loại credential.

Nhược điểm: người dùng phải mở app (hoặc dùng widget/hành động nhanh bạn tạo), truy cập màn hình khóa bị hạn chế bởi OS, và hành vi offline là trách nhiệm hoàn toàn của bạn.

Lựa chọn B: Apple Wallet / Google Wallet

Wallet pass (ví dụ PKPass trên iOS) quen thuộc và thiết kế cho trình bày nhanh.

Ưu điểm: độ tin cậy và dễ tìm cao, truy cập nhanh từ màn hình khóa, xử lý trình bày tốt phía OS, và hành vi "show code" nhanh.

Nhược điểm: ràng buộc nền tảng chặt hơn (định dạng barcode/NFC được hỗ trợ, UI tùy biến hạn chế), cập nhật tuân theo quy tắc Wallet, và bạn có thể cần cấu hình cụ thể Apple/Google (chứng chỉ, cấu hình issuer, đôi khi duyệt). Telemetry sâu cũng khó hơn.

Quy tắc ra quyết định thực tế

Dùng Wallet khi tốc độ, quen thuộc và khả năng luôn sẵn sàng quan trọng (khách, sự kiện, quy trình mã vạch đơn giản). Dùng in-app khi cần kiểm tra danh tính mạnh hơn, luồng phức tạp, hoặc logic credential phức tạp (nhân viên đa site, phê duyệt, phân quyền).

Nhiều loại pass, template và branding

Nếu bạn phục vụ nhiều tổ chức, lên kế hoạch cho template theo tổ chức: logo, màu sắc, hướng dẫn và trường dữ liệu khác nhau. Một số nhóm phát cả hai: pass Wallet cho vào nhanh và credential trong app cho quản trị và hỗ trợ.

Vòng đời pass bạn phải hỗ trợ

Bất kể container nào, định nghĩa các hành động vòng đời bạn có thể kích hoạt:

• Issue (lần đầu enroll)
• Update (tên, quyền truy cập, expiry, thay đổi hiển thị)
• Suspend (tạm giữ)
• Revoke (vô hiệu vĩnh viễn)
• Re-issue (thiết bị mới, mất điện thoại, nghi ngờ xâm phạm)

Giữ các thao tác này nhất quán giữa in-app và Wallet để đội vận hành quản lý truy cập mà không phải dùng thủ công.

Thiết kế mô hình dữ liệu và vòng đời pass

Một mô hình dữ liệu rõ ràng làm cho hệ thống còn lại dễ dự đoán: cấp pass, xác thực tại reader, thu hồi, và điều tra sự cố nên là các truy vấn rõ ràng chứ không phải suy đoán.

Thực thể lõi cần mô hình hóa

Bắt đầu với một tập nhỏ đối tượng "first-class" và mở rộng khi cần:

• User: người được quyền truy cập.
• Organization / Site: chủ sở hữu hệ thống (và nơi truy cập áp dụng).
• Pass: "thẻ" người dùng thấy (những gì app hoặc wallet hiển thị).
• Credential: token trình lên reader (credential NFC, payload QR, v.v.). Một pass có thể có nhiều credential theo thời gian.
• Device: phiên bản điện thoại giữ hoặc hiển thị credential.
• Reader / Door: đầu cuối vật lý (reader ID, door ID, vị trí).
• Access policy: quy tắc nối người/danh sách với cửa và lịch trình.

Sự phân tách này hữu ích khi người dùng đổi điện thoại: pass vẫn là cùng một khái niệm trong khi credential luân phiên và device thay đổi.

Trạng thái pass và vòng đời

Định nghĩa trạng thái rõ ràng và chỉ cho phép chuyển đổi có chủ đích:

• pending (đã được mời/đang enroll)
• active (có thể dùng)
• suspended (bị chặn tạm thời)
• expired (hết hạn theo thời gian)
• revoked (vô hiệu)

Ví dụ chuyển đổi: pending → active sau khi xác minh; active → suspended vì vi phạm chính sách; active → revoked khi kết thúc hợp đồng; suspended → active sau khi admin khôi phục.

Các định danh và ánh xạ tới reader

Lên kế hoạch ID duy nhất ở hai cấp:

• Một pass_id ổn định (nội bộ) cho vòng đời và hỗ trợ.
• Một hoặc nhiều credential_id / token_id mà reader có thể xác thực.

Quyết định cách reader ánh xạ token tới quy tắc truy cập: tra cứu trực tiếp (token → user → policy) hay token → nhóm policy (nhanh hơn ở edge). Giữ các định danh không đoán được (ngẫu nhiên, không theo thứ tự).

Audit logs: ghi gì và ở đâu

Xem audit logs như append-only và tách khỏi bảng "trạng thái hiện tại". Ít nhất ghi lại:

• issue (ai cấp, cho ai, thiết bị, thời gian)
• scan (reader, kết quả, mã lý do)
• deny (khớp chính sách thất bại, expired, revoked, lỗi offline)
• revoke/suspend/reactivate (actor, lý do, thời gian)

Những event này là nguồn chân lý để gỡ lỗi, tuân thủ và phát hiện lạm dụng.

Xây dựng luồng đóng ghi danh và phát hành pass

Dự án pass số thành công hay thất bại dựa vào trải nghiệm "5 phút đầu": người thật có thể enroll, nhận credential và hiểu phải làm gì tiếp theo nhanh ra sao.

Đường dẫn enrollment (chọn 1–2 chính)

Hầu hết đội hỗ trợ kết hợp các bước sau, tùy mức độ bảo mật và quy mô triển khai:

• Invite link: admin (hoặc hệ thống HR) tạo link có thời hạn. Người dùng mở trên điện thoại và vào thẳng luồng đúng.
• Xác thực Email/SMS: gửi mã một lần để xác nhận số điện thoại hoặc email gắn với hồ sơ danh tính.
• SSO: cho nhân viên, dùng SAML/OIDC để chỉ cấp pass sau khi đăng nhập doanh nghiệp.
• Phê duyệt admin: cho site an ninh cao, đặt yêu cầu vào hàng chờ review (với mã lý do, timestamp và audit trail).

Mẫu thực tế: invite link → xác thực email/SMS → (tùy chọn) SSO → cấp pass.

Cách thêm pass (và hướng dẫn người dùng)

Thiết kế issuance để người dùng không phải "tự mò":

• In-app pass: credential sống trong app của bạn; bạn kiểm soát cập nhật và UI. Tốt khi cần xác thực tùy biến, luật offline, hoặc hành vi reader đặc biệt.
• Wallet add: cung cấp nút “Add to Apple Wallet” / “Add to Google Wallet” sau khi xác thực. Hỗ trợ deep link mở màn hình thêm wallet từ invite.
• QR invitation fallback: tại chỗ, cho phép kiosk lễ tân hiển thị QR mở enrollment (hữu ích khi người dùng không tìm thấy email).

Giữ nội dung rất rõ: pass dùng để làm gì, sẽ xuất hiện ở đâu (app hay wallet), và làm gì tại cửa.

Thay đổi thiết bị và quy tắc cấp lại

Lên kế hoạch sớm để tránh ticket hỗ trợ:

• Điện thoại mới: cung cấp luồng re-enroll tự phục vụ xác minh danh tính và cấp lại pass.
• Nhiều thiết bị: quyết định có cho phép không. Nếu cho phép, giới hạn số lượng và hiển thị thiết bị đang hoạt động trong cài đặt.
• Thiết bị mất: cho phép revoke từ xa ngay lập tức, sau đó cấp lại sau khi xác minh lại.

Thông báo cho người dùng khi sự cố ngoài thực tế

Viết thông điệp thân thiện, cụ thể cho:

• Bị từ chối truy cập (và bước tiếp theo: “Liên hệ an ninh” vs “Thử làm mới lại”)
• Pass hết hạn (kèm ngày hết hạn và hành động gia hạn)
• Vấn đề kết nối (giải thích phần nào vẫn hoạt động offline, và cách phục hồi khi online)

Issuance tốt không chỉ là “tạo pass” — mà là một hành trình hoàn chỉnh, dễ hiểu với lộ trình phục hồi dự đoán được.

Xác thực và phân quyền cho người dùng và admin

Digital pass chỉ đáng tin khi danh tính và quyền phía sau nó đáng tin. Xem authentication (bạn là ai) và authorization (bạn được làm gì) là tính năng sản phẩm quan trọng, không chỉ là hạ tầng.

Chọn cách xác thực

Chọn phương pháp đăng nhập phù hợp với đối tượng và rủi ro:

• Email + mã dùng một lần (OTP): dễ cho người tiêu dùng, ít reset mật khẩu.
• Passwordless “magic link”: tốt cho đăng ký ít rào cản, nhưng cần gửi email tin cậy.
• SSO / nhận dạng doanh nghiệp (SAML/OIDC): tốt nhất cho nhân viên, nhà thầu và campus; liên kết truy cập với chính sách HR/IT hiện có.

Nếu bạn hỗ trợ nhiều tenant, quyết định sớm một người có thể thuộc nhiều tenant hay không và họ chuyển ngữ cảnh như thế nào.

Phân quyền: vai trò, phạm vi và khả năng kiểm toán

Định nghĩa vai trò bằng ngôn ngữ dễ hiểu (ví dụ Pass Holder, Front Desk, Security Admin, Auditor), sau đó ánh xạ sang quyền:

• Ai có thể issue, reissue, revoke, hoặc suspend pass
• Ai có thể xem log truy cập và xuất báo cáo
• Ai có thể thay đổi quy tắc facility (nhóm cửa, lịch trình)

Giữ kiểm tra phân quyền trên server (không chỉ ở UI), và ghi log mọi hành động nhạy cảm với ai, cái gì, khi nào, ở đâu (IP/thiết bị), cùng trường lý do cho các thao tác admin thủ công.

Session, độ tin tưởng thiết bị và tiện lợi cho người dùng

Dùng access token thời gian ngắn kèm refresh token, và hỗ trợ đăng nhập lại an toàn qua sinh trắc (Face ID/Touch ID) để hiển thị pass.

Với triển khai yêu cầu an ninh cao, thêm device binding để credential chỉ hợp lệ trên thiết bị đã enroll. Điều này cũng làm khó việc token bị sao chép dùng ở nơi khác.

Biện pháp cho admin giảm sai sót và lạm dụng

Công cụ admin cần thêm hàng rào:

• Luồng phê duyệt cho issuance hàng loạt hoặc pass quyền cao
• Giới hạn tần suất cho endpoint issuance/reissue
• Cảnh báo cho mẫu bất thường (ví dụ nhiều pass cho cùng domain email, spike ngoài giờ)

Ghi lại các chính sách này trong runbook nội bộ và liên kết từ UI admin (ví dụ: /docs/admin-security) để vận hành nhất quán.