Sự khác biệt giữa Authentication và Authorization

Authentication thiết lập ai hoặc cái gì đang hành động

Authentication thiết lập mức độ tin cậy với một danh tính được khẳng định hoặc xác thực thông tin xác thực gắn với một principal. Các định nghĩa về authentication của NIST bao quát việc xác minh danh tính trong nhiều ngữ cảnh. Principal có thể là một người, một ứng dụng hoặc một tài khoản dịch vụ, chứ không chỉ là người dùng.

Một API key thường nhận diện một ứng dụng hoặc tài khoản gọi, tùy theo mô hình của nhà cung cấp. Một cookie phiên trình duyệt có thể đại diện cho người dùng đã đăng nhập. Không nên mô tả bất kỳ giá trị nào là toàn bộ chính sách quyền chỉ vì nó cho phép máy chủ nhận diện bên gọi.

Để có một ví dụ thực tế, hãy tưởng tượng một dịch vụ báo cáo nội bộ chấp nhận một thông tin xác thực dịch vụ. Việc chấp nhận có thể xác lập rằng yêu cầu đến từ ứng dụng báo cáo. Nó không xác lập được ứng dụng có thể đọc bộ dữ liệu khách hàng nào. Hãy ghi lại principal đã được nhận diện ở dạng chẩn đoán an toàn, đồng thời không ghi thông tin xác thực thực tế vào log hoặc các tài liệu được chia sẻ.

Authorization đánh giá một hành động trên một tài nguyên

Authorization xác định liệu một principal có thể thực hiện hành động được yêu cầu theo một chính sách áp dụng hay không. Các định nghĩa về authorization của NIST mô tả việc cấp và đánh giá quyền truy cập. Một quyết định hữu ích bao gồm một chủ thể, một hành động, một tài nguyên và mọi ngữ cảnh liên quan.

Đối với một project API, đọc một dự án, chỉnh sửa cài đặt của nó và xóa nó là các hành động khác nhau. Một người dùng có thể được phép đọc một dự án và chỉnh sửa một dự án khác. Một tên vai trò tự thân không giải thích được kết quả trừ khi vai trò đó được ánh xạ tới đúng phạm vi tài nguyên và hành động.

Hãy làm rõ quyền sở hữu đối tượng. Nếu một endpoint nhận một định danh dự án, hãy truy xuất dự án và đánh giá quyền truy cập vào đối tượng đó thay vì chỉ kiểm tra liệu bên gọi đã đăng nhập hay chưa. Một định danh có thể đoán được không bao giờ nên là ranh giới quyền truy cập. Áp dụng cùng quy tắc cho các bản xuất, tệp đính kèm và các job nền phơi lộ dữ liệu của dự án.

Thông tin xác thực, phiên và token là các phương tiện mang claim

Một thông tin xác thực hoặc token mang thông tin hoặc bằng chứng mà hệ thống sẽ đánh giá; sự hiện diện của nó không quyết định mọi quyết định truy cập. Thông tin xác thực dạng bearer cần được chú ý đặc biệt vì chỉ cần sở hữu là có thể sử dụng. Đặc tả OAuth bearer-token định nghĩa mô hình bảo mật đó và mô tả các điều kiện lỗi liên quan đến token.

Giữ các cơ chế xác thực tách biệt. Một API mong đợi một khóa thô trong một header cụ thể không tự động trở thành một endpoint OAuth bearer-token. Một kết nối trình duyệt chấp nhận tham số token có bề mặt truyền tải khác với header yêu cầu REST. Hãy dùng phương thức được ghi trong tài liệu cho dịch vụ cụ thể đó.

Cũng cần phân biệt xác thực với mã hóa. TLS bảo vệ giao tiếp trong quá trình truyền, trong khi xác thực và ủy quyền kiểm soát danh tính và quyền truy cập tại ranh giới ứng dụng. Một kết nối đã mã hóa hợp lệ vẫn có thể truyền một yêu cầu chưa được xác thực hoặc một yêu cầu mà người gọi đã được nhận diện không được phép thực hiện.

Thực thi quyền trên mọi yêu cầu liên quan

Kiểm soát truy cập nên được thực thi tại ranh giới máy chủ cho tài nguyên và hành động được yêu cầu. Tài liệu OWASP authorization guidance khuyến nghị nguyên tắc ít đặc quyền nhất, từ chối theo mặc định, và xác thực quyền trên mọi yêu cầu. Những nguyên tắc này giúp ngăn một lần kiểm tra bị bỏ sót trở thành một sự cấp quyền ngoài ý muốn.

Giao diện phía khách có thể phản ánh quyền để tăng tính tiện dụng, nhưng một điều khiển bị ẩn không ngăn được một yêu cầu trực tiếp. Áp dụng cùng một chính sách khi hành động đến qua giao diện web, một API, một tác vụ theo lịch, hoặc một worker xuất dữ liệu. Xử lý nền cũng cần có danh tính và phạm vi được ghi rõ trong tài liệu.

Đối với một ứng dụng đa tenant, hãy kiểm tra trực tiếp ranh giới giữa các tenant. Một người dùng có quyền chỉnh sửa trong một không gian làm việc không được phép có quyền tương đương ở không gian khác chỉ bằng cách đổi một định danh. Giữ các yêu cầu bị từ chối trong bộ kiểm thử, gồm cả các yêu cầu cho những đối tượng tồn tại nhưng thuộc về một principal khác.

Việc xoay vòng thông tin xác thực và thay đổi quyền có các tác động khác nhau

Xoay vòng thông tin xác thực thay thế bằng chứng dùng để xác thực người gọi. Thay đổi quyền sửa đổi những gì một người gọi đã được nhận diện có thể làm. Hai thao tác này giải quyết các vấn đề khác nhau và có thể ảnh hưởng đến phiên đang chạy hoặc ứng dụng theo những cách khác nhau, tùy vào cách triển khai.

Nếu một bí mật bị lộ, việc xóa nó khỏi một tệp không làm mất hiệu lực thông tin xác thực. Hãy dùng quy trình vô hiệu hóa sẵn có của nhà cung cấp và phân phối một thông tin thay thế qua một kho bí mật được phê duyệt. Nếu người dùng thay đổi vai trò, hãy cập nhật chính sách ủy quyền và hiểu khi nào các phiên đang hoạt động hoặc các quyết định được cache sẽ ghi nhận thay đổi đó.

Giữ một bản ghi vận hành về ứng dụng nào sử dụng một thông tin xác thực mà không lưu trữ bí mật trong bản ghi đó. Điều này giúp xác định các triển khai bị ảnh hưởng trong quá trình xoay vòng. Tương tự, hãy ghi rõ tài liệu về quyền nào mà một tác vụ nền phụ thuộc vào. Một thông điệp chung chung rằng truy cập ngừng hoạt động sẽ dễ điều tra hơn nhiều khi danh tính, phạm vi tài nguyên và cấu hình triển khai được phân biệt rõ.

Áp dụng sự phân biệt này vào một kết nối Scrapeless

Một khóa API Scrapeless xác thực các yêu cầu đến Scrapeless, trong khi quyền truy cập sản phẩm và tính hợp lệ của yêu cầu vẫn cần được đánh giá riêng. Hướng dẫn hiện tại về Scrapeless API key handling phân biệt các phương thức truyền tải và giải thích vì sao một khóa được chấp nhận không chứng minh rằng mọi yêu cầu sản phẩm đều sẽ thành công.

Đối với Scrapeless Agent Browser, hãy xử lý một URL kết nối chứa thông tin xác thực như một bí mật. Ẩn giá trị nhạy cảm trước khi ghi log URL hoặc chia sẻ thông tin chẩn đoán. Làm theo phương thức kết nối được ghi trong tài liệu của client trình duyệt đã chọn thay vì cho rằng mọi API đều dùng cùng một header hoặc cú pháp token.

Sự phân biệt này cũng áp dụng tại website đích. Quyền gọi một dịch vụ hạ tầng không phải là quyền truy cập mọi tài nguyên thông qua nó. Hãy thu thập trong phạm vi được ủy quyền dự định. Tài liệu API authentication overview cung cấp thêm bối cảnh, và thông tin hiện tại về Scrapeless pricing nên được đặt trong việc lập kế hoạch năng lực và ngân sách hơn là xác minh danh tính.

Chẩn đoán danh tính trước khi thay đổi chính sách tài nguyên

Một cuộc điều tra truy cập nên xác định rõ thành phần nào đã đưa ra quyết định và nhận diện ra danh tính nào. Kiểm tra xem thông tin xác thực dự định có đến được dịch vụ mong đợi bằng sơ đồ được ghi trong tài liệu hay không. Kiểm tra phản hồi đã được ẩn bớt và mã nhận dạng tương quan thay vì công khai các header hoặc URL kết nối chứa bí mật.

Khi danh tính đã được xác lập, hãy kiểm tra hành động được yêu cầu và phạm vi tài nguyên. Kiểm tra quyền sở hữu, phân công vai trò và mọi giới hạn theo ngữ cảnh. Tránh cấp quyền quản trị rộng chỉ để làm biến mất một lỗi. Một chẩn đoán hẹp nên dẫn đến một thay đổi chính sách hẹp khi việc thay đổi là phù hợp.

Giữ các kiểm thử âm song song với các yêu cầu thành công. Kiểm thử một thông tin xác thực vắng mặt, một thông tin xác thực không hợp lệ, một người gọi hợp lệ nhưng không có quyền cần thiết, và một người gọi có đúng quyền dự định. Những trường hợp này cho thấy xác thực và ủy quyền có được thực thi độc lập hay không. Chúng cũng cung cấp cho đội hỗ trợ một vốn từ cụ thể để giải thích sự khác biệt mà không làm lộ chi tiết chính sách nhạy cảm.

Kết luận

Sự khác nhau giữa Authentication và Authorization là sự khác nhau giữa nhận diện người gọi và cho phép một hành động cụ thể. Hãy giữ bí mật thông tin xác thực, thực thi các quyền được giới hạn phạm vi trên mọi ranh giới liên quan, và kiểm thử kết quả bị từ chối một cách có chủ đích như với những kết quả thành công. Chẩn đoán rõ ràng giúp nhận diện principal và quyết định về tài nguyên mà không làm lộ vật liệu dùng để xác thực.

Tài liệu tham khảo

• Nhận và bảo vệ khóa Scrapeless API
• Trình duyệt Tác nhân Scrapeless
• Khái niệm về danh tính và thông tin xác thực API