OAuth là gì? Ủy quyền truy cập, Token và các luồng PKCE

Scrapeless Agent Browser hỗ trợ điều hướng trình duyệt và các quy trình làm việc dựa trên phiên, trong khi quyền OAuth vẫn thuộc trách nhiệm của ứng dụng và máy chủ ủy quyền.

OAuth là một khung cho ủy quyền được ủy nhiệm

OAuth là một khung ủy quyền cho phép ứng dụng có được quyền truy cập hạn chế vào các tài nguyên được bảo vệ mà không cần thu thập mật khẩu của chủ sở hữu tài nguyên cho các tài nguyên đó. Ví dụ, một người dùng có thể ủy quyền cho một công cụ lập lịch đọc lịch của họ, trong khi dịch vụ lịch kiểm soát các thao tác được cho phép. Công cụ lập lịch sẽ nhận được một thông tin xác thực cho quyền truy cập đó thay vì mật khẩu có thể tái sử dụng của người dùng.

Khung OAuth authorization framework định nghĩa các vai trò và tương tác cốt lõi. Chủ sở hữu tài nguyên kiểm soát tài nguyên liên quan, ứng dụng khách yêu cầu truy cập, máy chủ ủy quyền cấp thông tin xác thực theo chính sách của nó, và máy chủ tài nguyên lưu trữ API được bảo vệ. Một tổ chức có thể vận hành cả hai vai trò máy chủ, nhưng giữ cho các vai trò tách biệt giúp giải thích nơi diễn ra xác thực, quyết định quyền hạn và kiểm tra token.

Một token grant hẹp hơn nhiều so với quyền toàn diện để vận hành một tài khoản. Quyền truy cập có thể bị ràng buộc bởi scope, tài nguyên dự định, thời lượng và chính sách của máy chủ ủy quyền. Máy chủ tài nguyên vẫn kiểm tra xem thao tác đó có được phép hay không. Màn hình đồng ý mô tả quyền truy cập được yêu cầu, trong khi thông tin xác thực được cấp thực tế và việc thực thi từ phía máy chủ quyết định ứng dụng có thể làm gì sau khi đã được đồng ý.

Ủy quyền và xác thực trả lời những câu hỏi khác nhau

Ủy quyền xác định ứng dụng được phép thực hiện quyền truy cập nào; xác thực thiết lập danh tính trong một ngữ cảnh cụ thể. OAuth có thể liên quan đến việc người dùng đăng nhập tại máy chủ ủy quyền, nhưng tương tác đó không tự động cung cấp cho client một khẳng định danh tính chuẩn hóa, phù hợp cho hệ thống đăng nhập riêng của nó. Coi một access token bất kỳ như bằng chứng đăng nhập có thể tạo ra các vấn đề thay thế token và sai đối tượng nhận.

Lớp danh tính OpenID Connect identity layer bổ sung xác thực trên nền OAuth và định nghĩa một ID token để client xác minh. Access token được dùng cho dịch vụ tài nguyên, trong khi ID token phục vụ ngữ cảnh xác thực của client. Sự phân biệt này thể hiện rõ trong các tiêu chuẩn và nên tiếp tục hiển thị trong thiết kế ứng dụng. Gửi một ID token tới một API không liên quan không tương đương với việc trình bày đúng access token.

Đối với sản phẩm đăng nhập, hãy chọn tích hợp nhà cung cấp hỗ trợ rõ ràng giao thức danh tính yêu cầu và xác minh token của nó bằng giao thức đó. Đối với truy cập API được ủy nhiệm, hãy yêu cầu các quyền tối thiểu phù hợp và chỉ gửi thông tin xác thực truy cập thu được tới đúng dịch vụ dự định. Một nút duy nhất hướng tới người dùng có thể ẩn cả hai luồng, vì vậy hãy kiểm tra hợp đồng thực tế thay vì gọi mọi hành động đăng nhập mạng xã hội đơn giản là OAuth login.

Mã ủy quyền tách biệt chấp thuận trên trình duyệt khỏi việc sử dụng token

Luồng authorization code đưa người dùng đi qua máy chủ ủy quyền, nơi xác thực người dùng khi cần và đánh giá yêu cầu truy cập. Sau khi được chấp thuận, trình duyệt quay lại vị trí redirect đã đăng ký của client với một authorization code sống ngắn. Client sau đó trao đổi mã này tại token endpoint, sử dụng các tham số và phương thức xác thực phù hợp với loại client của nó.

Một mã không phải là thông tin xác thực API dùng để đọc các mục lịch hoặc bản ghi được bảo vệ khác. Mục đích của nó là kết nối tương tác ủy quyền qua kênh trình duyệt với quá trình trao đổi token phía sau. Giữ việc kiểm tra URI redirect thật nghiêm ngặt và ràng buộc phản hồi với giao dịch mà client đã khởi tạo. Một callback nhận được tại một origin không mong đợi hoặc thiếu ngữ cảnh giao dịch dự kiến không nên trở thành một phiên ứng dụng đã xác thực.

Một đăng ký client mô tả các chi tiết như vị trí redirect và các loại grant được phép. Một ứng dụng máy chủ có thể bảo vệ thông tin xác thực và một ứng dụng công khai được phân phối qua trình duyệt có các khả năng khác nhau. Không sao chép client secret phía máy chủ vào JavaScript có thể tải xuống. Mô hình phân phối của ứng dụng quyết định việc giá trị đó có thể được giữ bí mật hay không, bất kể nhãn gắn cho nó trong bảng điều khiển.

PKCE bảo vệ quá trình trao đổi mã

PKCE, hay Proof Key for Code Exchange, ràng buộc yêu cầu ủy quyền và trao đổi token bằng một verifier đặc thù cho giao dịch. Client tạo ra một challenge từ verifier và đưa challenge đó vào yêu cầu ủy quyền. Tại token endpoint, nó cung cấp verifier, cho phép máy chủ xác nhận rằng quá trình trao đổi thuộc về cùng một giao dịch đã khởi tạo.

Cơ chế PKCE mechanism giải quyết việc chặn bắt authorization code. PKCE không biến một ứng dụng công khai thành confidential client, và verifier không phải là mật khẩu client vĩnh viễn. Hãy tạo và giữ nó trong phạm vi giao dịch cụ thể, bảo vệ nó, và sử dụng một phương thức challenge được hỗ trợ mà không để lộ verifier trong yêu cầu ủy quyền.

current OAuth security best practice yêu cầu PKCE cho các public client trong authorization code flow và khuyến nghị dùng cho confidential client. Nó cũng đề cập đến việc khớp chính xác redirect, chèn mã (code injection) và rò rỉ token. Áp dụng các yêu cầu đó thông qua một triển khai OAuth được bảo trì thay vì tự lắp ghép một flow từ các đoạn mã rời rạc. Thư viện đúng vẫn cần cấu hình đúng issuer, redirect và resource.

Access Token và Refresh Token có vòng đời riêng biệt

Một access token mang hoặc tham chiếu đến quyền ủy quyền cần thiết cho một resource service. Định dạng của nó không bị khuôn cố định bởi khung OAuth chung: một dịch vụ có thể dùng giá trị mờ (opaque value) hoặc một token có cấu trúc. Client nên dựa vào các trường phản hồi được ghi trong tài liệu và yêu cầu của resource thay vì giả định mọi access token đều là một JSON Web Token có thể đọc được.

Refresh token là một thông tin xác thực khác dùng với authorization server để lấy access token. Nó không nên được gửi tới ordinary resource API. Việc server có phát hành hay không, nó còn hợp lệ bao lâu và áp dụng những biện pháp bảo vệ nào phụ thuộc vào client và chính sách của nhà cung cấp. Hãy bảo vệ nó như một bí mật có giá trị vì vòng đời của nó có thể kéo dài hơn một access token đơn lẻ.

Việc thu hồi (revocation) cũng có một giao diện được định nghĩa thay vì chỉ được ngầm hiểu là xóa một chuỗi cục bộ. Cơ chế OAuth token revocation cho phép một client thông báo cho authorization server rằng một token không còn cần thiết nữa. Local logout, thu hồi grant và chấm dứt mọi phiên ứng dụng có thể có những tác động khác nhau. Hãy ghi lại các tác động đó để người dùng hiểu việc ngắt kết nối một tích hợp thực sự thay đổi điều gì.

Scope, Audience và chính sách của Server giới hạn quyền truy cập

Scope mô tả các khả năng được yêu cầu hoặc được cấp trong vốn từ vựng của hệ thống ủy quyền. Tên gọi và ý nghĩa của chúng thuộc về nhà cung cấp. Một scope thiên về đọc vẫn có thể để lộ bản ghi nhạy cảm, nên chỉ yêu cầu những gì tính năng sản phẩm cần và giải thích lý do. Ứng dụng không nên yêu cầu quyền ghi rộng chỉ vì điều đó giúp phát triển trong tương lai dễ dàng hơn.

Resource hoặc audience dự kiến là một ranh giới khác. Một token được phát hành cho một dịch vụ không nên được chấp nhận như quyền ủy quyền có thể hoán đổi tại dịch vụ khác. Resource server phải xác thực issuer, audience, thời hạn và chi tiết ủy quyền liên quan bằng cơ chế token đã chọn. Một chữ ký hợp lệ tự thân nó không chứng minh rằng thông tin xác thực là phù hợp cho thao tác được yêu cầu.

Client credentials flow phục vụ quyền truy cập của ứng dụng trong các bối cảnh không đại diện cho sự đồng ý được ủy quyền của người dùng. Các flow hướng tới thiết bị xử lý những ràng buộc tương tác khác. Hãy chọn một grant được hỗ trợ cho đúng loại ứng dụng thực tế thay vì ép mọi sản phẩm dùng chung một flow quen thuộc. Việc một dịch vụ có nhắc tới OAuth trong tài liệu không có nghĩa là mọi grant, scope hoặc loại client đều khả dụng cho mọi tài khoản.

Tách biệt trạng thái trình duyệt khỏi OAuth credential

Cookie trình duyệt, một phiên ứng dụng và OAuth credential là những mối quan tâm triển khai có liên quan nhưng có vòng đời khác nhau. Trình duyệt có thể vẫn đăng nhập trong khi API token hết hạn, và một ứng dụng có thể giữ một token ủy quyền hợp lệ sau khi một cửa sổ xem cụ thể trên trình duyệt đóng lại. Chẩn đoán lỗi quyền hạn tại thành phần sở hữu thông tin xác thực liên quan thay vì sao chép trạng thái trình duyệt sang các dịch vụ không liên quan.

Các yêu cầu xử lý khóa API của Scrapeless mô tả một thông tin xác thực riêng được dùng để truy cập các sản phẩm Scrapeless. Một khóa API của Scrapeless không phải là một OAuth access token cho website mục tiêu. Các phương thức xác thực API liên quan giúp phân biệt các cơ chế thông tin xác thực, và Scrapeless pricing tính phí việc sử dụng dịch vụ chứ không phải quyền ủy quyền với bên thứ ba.

Xem xét một tích hợp được ủy quyền trước khi mở rộng nó

Một tích hợp được ủy quyền nên có một bảng kê quyền hạn rõ ràng. Ghi lại issuer, resource dự kiến, scope được yêu cầu, loại client, địa chỉ redirect, cách lưu trữ credential và hành vi khi ngắt kết nối. Tách biệt telemetry ứng dụng thông thường khỏi dữ liệu yêu cầu mang token để log thông thường không trở thành kho lưu trữ credential không kiểm soát. Kiểm thử ranh giới quyền hạn với các tài khoản đã được ủy quyền và các mức truy cập được ghi trong tài liệu.

Một tích hợp lịch giả định có thể bắt đầu với quyền chỉ‑đọc cho một tính năng đã được người dùng chấp thuận. Tiêu chí chấp nhận của nó nên bao gồm đúng tài khoản, các tài nguyên lịch được cho phép, một quy trình ngắt kết nối hoạt động được và không có bí mật nào trong nhật ký hiển thị với phía client. Chỉ mở rộng quyền khi có một tính năng cụ thể thực sự cần chúng. Kỷ luật đó giúp dễ giải thích yêu cầu chấp thuận và giới hạn hậu quả khi thông tin xác thực bị lộ.

Kết luận

OAuth ủy quyền quyền truy cập cụ thể thông qua các vai trò được định nghĩa, thông tin xác thực và chính sách của máy chủ. Chọn luồng phù hợp với loại client thực tế, dùng PKCE khi được yêu cầu và giữ cho khẳng định danh tính tách biệt với access token dùng cho tài nguyên. Một tích hợp có thể bảo trì được làm rõ phạm vi, ranh giới lưu trữ và hành vi ngắt kết nối trước khi xử lý dữ liệu tài khoản nhạy cảm.