Giới Thiệu

Khi xây dựng một ứng dụng, bạn sẽ cần một biểu mẫu đăng nhập. Trong đó, bạn sẽ thu thập email và mật khẩu của người dùng, gửi chúng đến một API và... một điều gì đó xảy ra. Người dùng sẽ được đăng nhập sau đó. Nhưng điều gì xảy ra ở đây? Ứng dụng của bạn quyết định ai được vào và họ có thể xem những gì dựa trên tiêu chí nào?

Bài viết này là bài đầu tiên trong chuỗi bài viết có tên "Khám Phá Danh Tính". Những bài viết trên blog này sẽ sử dụng ghi chú của tôi khi tôi bắt đầu tìm hiểu về các khái niệm danh tính với tư cách là một Developer Advocate. Hãy coi chúng như cuốn sổ phác thảo về Danh Tính của tôi và tham gia cùng tôi trong hành trình trở về quá khứ! ❤️

Trong chuỗi bài viết này, tôi sẽ trình bày các ý tưởng cốt lõi của danh tính hiện đại thông qua một câu chuyện đơn giản, liên tục: không có thông số kỹ thuật phức tạp, chỉ có những giải thích rõ ràng và thực tiễn dành cho các nhà phát triển web. Hôm nay, tôi bắt đầu với hai khái niệm quan trọng nhất: Xác thực (Authentication) và Ủy quyền (Authorization). Bạn có thể nghĩ về chúng như một người bảo vệ kiểm tra ID ở cửa ra vào và một bảng ghi danh sách quyền của bạn.

Xác Thực Là Gì? Phép So Sánh Với Người Bảo Vệ

Bạn có biết về Người Bảo Vệ Thuyết Phục không? Đó là một loạt comic bốn khung dễ khai thác, với một người đàn ông trong bộ suit chặn cửa và cho phép vào ở khung thứ tư. Đây là cách tôi hình dung về Xác thực (và tôi rất thích vẽ meme 😁). Hãy nghĩ về xác thực như thế này: Xác thực là người bảo vệ đứng ở cửa trước, ví dụ như của một địa điểm. Trong thực tế, địa điểm đó chính là ứng dụng của bạn. Để vào được, bạn phải trình ID của mình, chứa thông tin xác thực của bạn.

Hãy hình dung điều này. Trong khung đầu tiên, chúng ta thấy Người Bảo Vệ chặn cửa khi một người dùng trình ID với thông tin xác thực của họ. Khi Người Bảo Vệ xác minh ID đó, khóa sẽ bật mở, và như chúng ta thấy trong khung thứ hai, anh ta cuối cùng mở cửa.

Và đó là tất cả: Bạn đã được xác thực! Tóm tắt cho quá trình này là Authn.

Về cơ bản, xác thực là việc chứng minh rằng một ai đó hoặc một cái gì đó là đúng như họ nói. Nó giống như khóa ở cửa ứng dụng của bạn. Khi nói về Authn trong một kịch bản danh tính, thường có nghĩa là xác minh thông tin xác thực. Những thông tin này đến từ nhiều hình thức khác nhau; trong khi sự kết hợp giữa tên người dùng và mật khẩu là ví dụ cổ điển, chúng cũng có thể là một cặp khóa riêng và công khai. Các phương pháp hiện đại thậm chí bao gồm xác thực không mật khẩu, xác minh danh tính của người dùng bằng một cái gì đó khác ngoài mật khẩu, chẳng hạn như một liên kết ma thuật được gửi đến email của họ hoặc một đặc điểm sinh trắc học như dấu vân tay.

Ủy Quyền Là Gì? Phép So Sánh Với Bảng Ghi Danh Sách Quyền

Chỉ vì bạn ở trong phòng không có nghĩa là bạn có thể làm bất cứ điều gì bạn muốn. Đây là lúc Ủy quyền xuất hiện, giống như người bảo vệ đưa cho bạn một bảng ghi danh sách quyền. Hãy tưởng tượng bảng ghi này như một danh sách kiểm tra hoặc quy tắc giải thích cho bạn các quyền hạn của bạn:

Bạn thấy đấy, bảng ghi này liệt kê chính xác những gì bạn được phép làm. Như bạn có thể thấy trong bản phác thảo, bạn có thể có quyền xem các phòng và ghi vào sổ khách, nhưng quyền thay đổi cài đặt điều hòa không khí thì bị gạch bỏ. Một quy tắc quan trọng là người bảo vệ sẽ luôn kiểm tra ID của bạn trước khi đưa cho bạn bảng ghi. Bạn phải chứng minh ai bạn là trước khi bạn có thể nhận được danh sách những điều bạn có thể làm.

Cách nhìn ngắn gọn của tôi: Khi một người dùng bước vào cửa, chúng ta phải biết họ có thể làm gì. Đó là Ủy quyền. Ủy quyền kiểm tra xem ai đó hoặc một cái gì đó có quyền truy cập vào một tài nguyên cụ thể hay được phép thực hiện một hành động cụ thể nào đó hay không. Tóm tắt cho Ủy quyền là Authz.

Cách Thức Hoạt Động Trong Một Ứng Dụng Frontend Thực Tế

Vậy, câu chuyện về người bảo vệ và bảng ghi này diễn ra như thế nào trong một ứng dụng web thực tế? Hãy cùng đi qua điều đó.

Một người dùng mới đến trang web của bạn và nhấp vào liên kết "Hồ Sơ Của Tôi".
Người bảo vệ trong ứng dụng của bạn chặn họ, thấy họ chưa có ID hợp lệ, và gửi họ đến trang đăng nhập.
Người dùng cung cấp thông tin xác thực của họ (ID của họ). Hệ thống kiểm tra và xác nhận danh tính của họ. Xác thực bây giờ đã thành công.
Bây giờ mà ứng dụng của bạn biết ai là người dùng, nó chuẩn bị bảng ghi quyền cá nhân của họ.
Người dùng được gửi đến trang "Hồ Sơ Của Tôi". Họ có thể xem tất cả thông tin cá nhân của họ, nhưng nút "Bảng Điều Khiển Quản Trị" bị ẩn. Tại sao? Bảng ghi của họ nói rằng họ không có quyền truy cập vào quyền admin_panel. Đó chính là Ủy quyền đang hoạt động.

Hiểu được sự khác biệt này là rất quan trọng đối với bạn với tư cách là một nhà phát triển frontend, vì nó ảnh hưởng trực tiếp đến giao diện người dùng mà bạn xây dựng hàng ngày. Một số mã giả cho thấy cách mà logic này có thể trông như thế nào bên trong một thành phần. Điều này có quen thuộc với bạn không?

javascript Copy

// Trong một thành phần hiển thị thanh điều hướng
function Navbar({ user }) {
  // Người bảo vệ kiểm tra ID (Xác thực)
  if (!user.isAuthenticated) {
    return <LoginButton />;
  }
  // Nếu được xác thực, người bảo vệ kiểm tra bảng ghi (Ủy quyền)
  return (
    <div>
      <WelcomeMessage user={user} />
      <ProfileLink />
      {/* Kiểm tra bảng ghi cho một quyền cụ thể */}
      {user.hasPermission('access:admin_panel') &&
        <AdminPanelLink />
      }
      <LogoutButton />
    </div>
  );
}

Tuy nhiên, đừng lo lắng! Bài viết blog này sẽ xoay quanh các ghi chú phác thảo của tôi, vì vậy tôi đã chuẩn bị một số thứ. Hãy cùng xem xét quy trình này:

Bạn thấy đấy, Authn và Authz không phải là điều giống nhau. Tuy nhiên, chúng thuộc về nhau: Xác thực là bước đầu tiên (tôi sẽ thậm chí gọi nó là nền tảng), để cho Authz có thể diễn ra. Điều đó có lý, vì bạn cần phải biết người dùng của bạn trước khi quyết định quyền của họ, đúng không?

Nhưng Có Những Loại Bảng Ghi Khác Nhau!?

Kiểm tra .hasPermission('...') đơn giản trong mã của chúng ta thực sự mạnh mẽ. Tuy nhiên, điều này làm tôi nghĩ. Hệ thống làm thế nào để quyết định quyền của người dùng ngay từ đầu? Bảng ghi của người bảo vệ không chỉ là một danh sách đơn giản. Hãy nhanh chóng xem xét các biến thể phổ biến nhất, vì tôi đã phác thảo bốn loại bảng ghi trong các bản phác thảo của mình.

Quản lý quyền truy cập dựa trên vai trò (RBAC) phân bổ quyền cho người dùng dựa trên vai trò của họ, chẳng hạn như “quản trị viên,” “biên tập viên,” hoặc “người xem.” Trong phép so sánh mà tôi đang sử dụng trong các bản phác thảo của mình, đây giống như “chiếc mũ” mà người dùng đang đội. Thay vì cung cấp một bộ quyền duy nhất, RBAC cung cấp các quyền tùy chỉnh tương ứng với từng vai trò cụ thể.

Quản lý quyền truy cập dựa trên thuộc tính (ABAC) là một mô hình ủy quyền xác định quyền truy cập dựa trên các thuộc tính (hoặc đặc điểm) của người dùng thay vì vai trò. Nó tương tự, nhưng không giống như Quản lý quyền truy cập dựa trên chính sách (PBAC): Chúng thường được coi là giống nhau nhưng không phải. Trong cảnh của chúng ta, chúng là “nhãn” mà người dùng có trên thẻ hội nghị của họ, chẳng hạn như “Người tham dự”, “Diễn giả”, hoặc thời gian khi họ đăng ký. ABAC bảo vệ tài nguyên khỏi những người dùng không được ủy quyền và những hành động không phù hợp với các nhãn đã được phê duyệt (về cơ bản là các thuộc tính) được thiết lập bởi các chính sách bảo mật của tổ chức.

Quản lý quyền truy cập dựa trên mối quan hệ (ReBAC) xử lý các quyết định truy cập dựa trên các mối quan hệ của một đối tượng. Một đối tượng như vậy có thể là một người dùng, thiết bị hoặc ứng dụng. Hoặc trong bản phác thảo của tôi, nó được hình dung như một danh sách khách, nơi chỉ có gia đình được thêm vào. Khi một đối tượng cố gắng truy cập một sự kiện hoặc tài nguyên (trong thực tế), hệ thống đánh giá các mối quan hệ cụ thể liên quan đến đối tượng đó để quyết định xem có nên cấp quyền truy cập hay không. Trong phép so sánh của tôi, nó có thể trông như thế này:

Cuối cùng, có Ủy quyền ủy quyền. Nó cho phép một người dùng cấp cho một ứng dụng quyền truy cập vào dữ liệu của họ từ một dịch vụ khác, mà không cần chia sẻ mật khẩu của họ, giống như ai đó trình ID của họ và một tài liệu do một người khác phát hành yêu cầu cho phép họ vào phòng thay mặt cho họ. Người dùng sẽ phải phê duyệt quyền truy cập được yêu cầu bởi bên thứ nhất để được chia sẻ bởi bên thứ ba. Quyền truy cập này bị giới hạn trong các quyền mà người dùng cấp. Ví dụ, LinkedIn sẽ chỉ được quyền truy cập vào danh bạ Gmail của chúng tôi, nhưng không phải hộp thư đến hoặc lịch của chúng tôi.

Kết Luận

Và đó là tất cả cho bản phác thảo đầu tiên của tôi! Câu chuyện đơn giản như vậy:

Xác thực (Authn) là hành động được thực hiện bởi Người Bảo Vệ: Họ kiểm tra ID của bạn để chứng minh bạn là ai.
Ủy quyền (Authz) là hành động cung cấp Bảng Ghi cho người đó, tức là người dùng. Nó liệt kê những gì bạn có thể làm khi bạn đã vào bên trong. Và bạn không bao giờ có thể nhận được bảng ghi của mình cho đến khi người bảo vệ đã phê duyệt ID của bạn.

Hãy cùng nhìn lại toàn bộ hành trình trong một bức tranh duy nhất để kết nối tất cả lại với nhau. Từ việc kiểm tra ID ban đầu bởi Người Bảo Vệ đến các loại Bảng Ghi khác nhau mà anh ta sử dụng, đây là toàn bộ câu chuyện từ cuốn sổ phác thảo Danh Tính của tôi:

Tuyệt vời, người dùng của bạn giờ đã được xác thực và vào trong ứng dụng! ❤️ Tuy nhiên, bạn có thể đã đoán trước được, Danh tính không dừng lại ở đây. Làm thế nào ứng dụng nhớ họ khi họ điều hướng từ trang này sang trang khác? Họ không cần phải trình ID của họ cho mỗi lần nhấp chuột. Làm thế nào "bảng ghi" của họ được mang theo bên mình?
Trong bài viết tiếp theo, tôi sẽ cho bạn thấy câu trả lời: Hộ chiếu Kỹ thuật số, còn được gọi là JSON Web Token (JWT). Hãy theo dõi nhé! 🔥

Trong thời gian chờ đợi, có một số bài đọc thú vị nếu bạn muốn tìm hiểu sâu hơn:

Xác thực và Ủy quyền cho các nhà phát triển xây dựng ở quy mô toàn cầu
Xác thực, Ủy quyền và Kế toán cho các nhà phát triển
Năm Ruby Gems cho Xác thực và Ủy quyền

Khám Phá Danh Tính: Xác Thực và Ủy Quyền