Hãy dùng "permissions" và "login" thay cho "auth"

• Thuật ngữ "auth" mang hai nghĩa: xác thực (authentication) và phân quyền (authorization)
• Điều này gây ra sự nhầm lẫn trong tên thư viện hoặc package
• Các thuật ngữ "authn" và "authz" không rõ ràng và khó hiểu

Sự khác biệt giữa xác thực và phân quyền

• Xác thực (authentication): quá trình xác minh người dùng là ai
• Phân quyền (authorization): quá trình quyết định người dùng có thể làm gì
• Hai khái niệm này khác nhau, và giải quyết một cái không có nghĩa là cái kia cũng được giải quyết

Đề xuất dùng "permissions" và "login"

• Đề xuất phân biệt rõ xác thực là "login", còn phân quyền là "permissions"
• "login" có thể được dùng ở cả dạng danh từ và động từ
  • Danh từ: thông tin được nhập để truy cập hệ thống
  • Động từ: hành động đăng nhập để sử dụng hệ thống
• "permissions" được dùng ở dạng danh từ, còn dạng động từ thì dùng "check permissions"

Lợi ích của việc dùng thuật ngữ rõ ràng

• Ngay cả những người ngoài ngành kỹ sư phần mềm cũng có thể dễ dàng hiểu được
• Cho phép tạo ra các tầng trừu tượng tốt hơn
• Có thể thiết kế bằng cách tách xác thực và phân quyền thành các mô-đun riêng biệt

Ý kiến của GN⁺

• Tầm quan trọng của việc dùng thuật ngữ rõ ràng: Khi thuật ngữ rõ ràng, việc giao tiếp trở nên trôi chảy hơn và có thể giảm hiểu lầm.
• Lợi ích của trừu tượng hóa: Tách xác thực và phân quyền giúp thiết kế hệ thống linh hoạt hơn và dễ bảo trì hơn.
• Ví dụ về việc dùng thuật ngữ khác: Ngoài "login" và "permissions", các thuật ngữ như "access control" cũng đáng để cân nhắc.
• Điều cần lưu ý khi áp dụng thuật ngữ: Khi đưa thuật ngữ mới vào, cần có đủ thảo luận và sự đồng thuận trong nhóm.
• Gợi ý dự án liên quan: Những dự án tiêu biểu tách riêng xác thực và phân quyền có OAuth và OpenID Connect.

[savvykang]

Giữa các lập trình viên, tôi thấy có thể đồng ý với việc dùng authn, authz thay vì auth, còn trong tài liệu hoặc controller/facade có điểm chạm với người dùng thì dùng login, permission. Tuy vậy, nếu đến mức muốn bỏ cả authn, authz thì tôi không chắc có cần làm vậy không.

[gcback]

Đúng như bài viết đã chỉ ra, việc dùng auth với nghĩa mơ hồ giữa xác thực và phân quyền đúng là từng gây khá nhiều nhầm lẫn. Có vẻ đây là một nỗ lực đáng hoan nghênh nhằm tách bạch bằng các thuật ngữ phổ thông hơn để giao tiếp với những lĩnh vực khác ngoài các nhà phát triển thuần túy.

[nemorize]

Nếu vấn đề là cả Authentication và Authorization đều có thể được rút gọn thành Auth,
thì như đã được nhắc trong bài, dùng Authn và Authz có lẽ là đủ rồi...
Nếu vẫn thấy cách đó chưa đủ rõ ràng, thì mở rộng thêm thành Authenty và Authory cũng không sao.

[koxel]

Hệ thống phân quyền thì lại có kiểu permission, có kiểu ACL nữa, vậy rồi định phân biệt thế nào đây..?
Nghe có vẻ hơi gượng ép...

[namarie32ilu]

Có lẽ đây là một nỗ lực nhằm giảm chi phí giao tiếp với các thành viên không thuộc nhóm phát triển, nhưng hơi quá tay một chút.

[iolothebard]

Không phải là người ta cố tình gộp cả hai lại rồi gọi là auth sao?

[kuber]

Đã có authentication và authorization rồi, tại sao còn nhất quyết dùng...

[GN⁺]

Ý kiến Hacker News

• "Authorize" và "Authenticate" là những từ rất tốt đã được dùng từ thời trung cổ. Ý nghĩa của hai từ này hầu như không thay đổi nhiều.
• Hai từ này có sự khác biệt quan trọng trong các hệ thống mật mã. Đổi từ để giảm nhầm lẫn có lẽ sẽ không giúp ích nhiều.
• Lập luận rằng cái tên "auth" gây ra nhầm lẫn không thật sự thuyết phục. Việc đổi từ có vẻ sẽ không giải quyết được vấn đề.
• Nên dùng các từ viết tắt "authn" và "authz". Tuy nhiên, dùng đầy đủ các từ dài cũng không sao.
• "Identity" và "Access" Management (IAM) là thuật ngữ tiêu chuẩn. Cá nhân tôi thích thuật ngữ "authnz" hơn.
• "Login" không bao hàm xác thực dựa trên token hay khóa. Tài khoản dịch vụ không đăng nhập nhưng vẫn cần xác thực và ủy quyền.
• Ranh giới giữa Authn và Authz không phải lúc nào cũng rõ ràng. Đôi khi có vẻ mọi người thích những từ nghe hay hơn là những thuật ngữ rõ ràng.
• Tôi chưa từng gặp vấn đề khi dùng thuật ngữ "auth" trong các hệ thống IAM. Khi cần diễn đạt cụ thể hơn thì chỉ cần dùng cụm từ phù hợp.
• "login" và "permissions" không nắm bắt được đầy đủ ý nghĩa và độ phức tạp của toàn bộ hệ thống. Xác thực mang nhiều ý nghĩa hơn là chỉ đăng nhập.
• Xác thực và ủy quyền có liên hệ chặt chẽ với nhau. Không thể ủy quyền nếu không có xác thực.
• Đăng nhập không phải là từ thay thế phù hợp cho xác thực. Có những trường hợp xác thực không cần đăng nhập.
• "auth" có thể mang nghĩa bao gồm cả xác thực lẫn ủy quyền. Vì hai khái niệm này thường được dùng cùng nhau.
• Xác thực và ủy quyền là thuật ngữ tiêu chuẩn trong CNTT và an toàn thông tin. Để tránh nhầm lẫn, tốt hơn nên dùng các từ đầy đủ.
• "authn" và "authz" đủ phổ biến để dùng giữa những người làm kỹ thuật. Với công chúng nói chung, nên dùng "login" và "permissions".
• Ngoài đời thực cũng có những khái niệm tương tự. Ví dụ, thẻ nhân viên vừa xác minh danh tính vừa cấp quyền truy cập.
• Ủy quyền và quyền hạn không phải là một. Quyền hạn là các quyền hoặc đặc quyền chưa được gán cho một người dùng cụ thể.
• Ủy quyền có thể mang hai nghĩa. Đó là quá trình cấp cho người dùng quyền thực hiện một hành động cụ thể, và quá trình kiểm tra điều đó.
• "access control" có thể chỉ việc kiểm soát truy cập ở thời điểm chạy. Đây là việc ứng dụng thực hiện sau khi người dùng đã được xác thực.
• "authN" và "authZ" là đủ phù hợp và được hiểu rõ. Ủy quyền luôn gắn với việc liên kết quyền hạn với người dùng.