OAuth là gì? Vai trò, Quy trình, Mã thông báo và Những điều cơ bản về bảo mật

API Scraping không cần scrap sử dụng một khóa API trong tiêu đề x-api-token, cung cấp sự tương phản cụ thể với mô hình ủy quyền ủy quyền của OAuth.

OAuth là gì?

OAuth là một khung cho ủy quyền ủy quyền. Nó cho phép một ứng dụng yêu cầu quyền truy cập hạn chế vào các tài nguyên được bảo vệ mà không yêu cầu người dùng cung cấp mật khẩu của dịch vụ sở hữu các tài nguyên đó. Người dùng tương tác với máy chủ ủy quyền, phê duyệt quyền truy cập được yêu cầu, và khách hàng nhận được một mã thông báo thay vì thông tin xác thực chính của người dùng.

RFC 6749 định nghĩa khung ủy quyền OAuth 2.0.Nó mô tả các vai trò, điểm cuối giao thức, cấp ủy quyền, mã thông báo truy cập, và mã thông báo làm mới. Các tài liệu sau này cập nhật khung và cung cấp hướng dẫn bảo mật cho các triển khai hiện tại.

OAuth cũng có thể ủy quyền cho các máy khách máy tính hành động thay mặt cho họ. Cấp ủy quyền thông tin xác thực khách hàng được thiết kế cho một khách hàng bí mật truy cập tài nguyên dưới một mối quan hệ dịch vụ đã thiết lập. Quy trình này khác với việc người dùng phê duyệt một ứng dụng của bên thứ ba.

Bốn vai trò của OAuth

Một tổ chức có thể điều hành cả máy chủ ủy quyền và máy chủ tài nguyên, nhưng chúng vẫn giữ vai trò giao thức tách biệt. Giữ các vai trò rõ ràng giúp các nhóm đặt xác thực và chính sách vào ranh giới chính xác.

Cách Quy trình Mã ủy quyền hoạt động

1. Khách hàng tạo ra một yêu cầu ủy quyền. Nó gửi trình duyệt đến điểm cuối ủy quyền với một định danh khách hàng, phạm vi yêu cầu, URI chuyển hướng, trạng thái, và thử thách PKCE.
2. Máy chủ ủy quyền xử lý tương tác của người dùng. Nó xác thực người dùng khi cần thiết và hiển thị quyền truy cập đang được yêu cầu.
3. Chủ sở hữu tài nguyên cấp quyền hoặc từ chối quyền truy cập. Sự đồng ý và chính sách xác định liệu mã ủy quyền có được cấp hay không.
4. Trình duyệt quay lại URI chuyển hướng đã đăng ký. Phản hồi bao gồm mã ủy quyền và giá trị trạng thái.
5. Khách hàng xác thực phản hồi. Nó so sánh trạng thái với giá trị gắn liền với phiên trình duyệt khởi tạo.
6. Khách hàng trao đổi mã. Nó gọi điểm cuối token với mã và trình xác minh PKCE; một khách hàng bảo mật cũng sử dụng phương pháp xác thực đã được phê duyệt.
7. Máy chủ ủy quyền cấp phát token. Phản hồi thường bao gồm một token truy cập và có thể bao gồm một token làm mới theo chính sách của máy chủ.
8. Khách hàng gọi máy chủ tài nguyên. Máy chủ tài nguyên xác thực token và thực thi phạm vi, đối tượng và chính sách cấp độ tài nguyên.

Mã ủy quyền là một thông tin xác thực trung gian, không phải là token API cuối cùng. Gửi token truy cập trực tiếp qua phản hồi ủy quyền đối diện với trình duyệt có thể khiến nó bị phơi bày trước nhiều bề mặt kênh trước. Thực tiễn hiện tại giữ việc trao đổi token truy cập tại điểm cuối token và bảo vệ nó bằng PKCE và xác thực khách hàng khi cần thiết.

PKCE là gì?

PKCE là viết tắt của Proof Key for Code Exchange. Khách hàng tạo ra một trình xác minh có độ ngẫu nhiên cao cho một lần cố gắng ủy quyền và gửi một thách thức được phát sinh với yêu cầu ủy quyền. Trong quá trình trao đổi mã, khách hàng trình bày trình xác minh. Máy chủ ủy quyền tính toán lại thách thức và chỉ chấp nhận mã khi các giá trị khớp nhau.

RFC 7636 định nghĩa PKCE.Nó được tạo ra để bảo vệ mã ủy quyền bị chặn từ các chuyển hướng khách hàng công cộng, và hướng dẫn bảo mật hiện tại áp dụng rộng rãi cho các luồng mã ủy quyền. Sử dụng phương pháp thách thức bảo mật được hỗ trợ bởi hồ sơ tiêu chuẩn thay vì một biến đổi trình xác minh đơn giản.

PKCE không thay thế trạng thái. PKCE ràng buộc việc trao đổi mã với phiên bản khách hàng khởi tạo. Trạng thái ràng buộc phản hồi ủy quyền với tương tác trình duyệt và giúp bảo vệ chống lại việc giả mạo yêu cầu giữa các trang và nhầm lẫn trong việc xử lý phiên khách hàng.

Token truy cập và token làm mới

Một token truy cập đại diện cho quyền được cấp cho một khách hàng. Máy chủ tài nguyên sử dụng nó để quyết định xem yêu cầu có thể truy cập vào tài nguyên và hoạt động được yêu cầu hay không. Token có thể không rõ ràng, yêu cầu kiểm tra nội dung hoặc tìm kiếm phía máy chủ, hoặc tự chứa trong hồ sơ token đã ký xác định.

Một token làm mới cho phép một khách hàng yêu cầu một token truy cập mới mà không cần tương tác với người dùng lần nữa. Nó thường chỉ được gửi đến máy chủ ủy quyền, không phải đến máy chủ tài nguyên. Các token làm mới là thông tin xác thực có giá trị lâu dài và cần được lưu trữ an toàn, ràng buộc khách hàng, điều khiển chu trình hoặc phát lại được xác định bởi máy chủ và hỗ trợ thu hồi.

Định dạng token tách biệt với luồng OAuth. OAuth không yêu cầu JSON Web Tokens. Một token truy cập không rõ ràng có thể được ưu tiên khi chính sách trung tâm và thu hồi ngay lập tức là quan trọng. Một token tự chứa có thể giảm nhu cầu kiểm tra nhưng cần xác thực cẩn thận về phát hành, đối tượng, chữ ký, tuyên bố thời gian và các thuật toán được cho phép của hồ sơ.

Phạm vi, Đối tượng và Đồng ý

Một phạm vi là một chuỗi được định nghĩa bởi máy chủ ủy quyền đại diện cho một quyền hoặc hạng mục truy cập. Một khách hàng yêu cầu các phạm vi, nhưng máy chủ có thể cấp phát quyền lực ít hơn dựa trên sự đồng ý và chính sách. Tên phạm vi nên mô tả các khả năng có ý nghĩa thay vì phản ánh từng điểm cuối nội bộ.

Đối tượng xác định máy chủ tài nguyên hoặc tập tài nguyên mà nó nhắm đến. Một token được cấp phát cho một API không nên được chấp nhận bởi một API không liên quan chỉ vì chữ ký của nó hợp lệ. Máy chủ tài nguyên phải xác thực đối tượng và người phát hành mà họ mong đợi.

Sự đồng ý không phải là sự thay thế cho chính sách. Người dùng không nên có khả năng cấp phát quyền mà họ không sở hữu. Máy chủ ủy quyền và máy chủ tài nguyên vẫn thực thi các hạn chế về người thuê, vai trò, quyền sở hữu, rủi ro và cấp độ tài nguyên.

Khách hàng công khai và bí mật

Một khách hàng bí mật có thể bảo vệ thông tin xác thực thông qua một môi trường được điều khiển bởi nhà điều hành của nó, chẳng hạn như một dịch vụ hậu cần. Một khách hàng công khai chạy ở nơi mà một bí mật không thể được giữ, chẳng hạn như trình duyệt hoặc ứng dụng đã được cài đặt phân phối đến người dùng. Việc vận chuyển cùng một bí mật khách hàng trong mỗi bản sao của một ứng dụng công khai không biến những bản sao đó thành bí mật.

Các khách hàng công khai dựa vào PKCE, xử lý chuyển hướng chính xác, bảo vệ nền tảng và quyền hạn token hạn chế hơn là một bí mật nhúng chia sẻ. Các khách hàng bí mật sử dụng phương pháp xác thực được phê duyệt bởi máy chủ ủy quyền tại điểm cuối token và phải bảo vệ các thông tin xác thực đó thông qua vòng đời bí mật.

OAuth so với Khóa API

Khóa API thường xác định một khách hàng hoặc dự án trực tiếp. Nó hoạt động tốt cho một mối quan hệ máy chủ đến máy chủ được kiểm soát nơi chủ sở hữu tài khoản cung cấp thông tin xác thực. OAuth thêm một giao thức để nhận token theo một khoản cấp, bao gồm quyền truy cập được ủy quyền cho người dùng với sự đồng ý và phạm vi.

Sử dụng một khóa API khi dịch vụ hậu cần truy cập tài khoản của chính nó và mô hình khóa của nhà cung cấp cung cấp các hạn chế có đủ. Sử dụng OAuth khi các khách hàng bên thứ ba cần quyền truy cập hạn chế thay mặt cho người dùng, khi quyền cần sự thu hồi độc lập, hoặc khi một hệ sinh thái yêu cầu các luồng ủy quyền chuẩn hóa.

Không có tùy chọn nào tự động an toàn. Khóa API cần được lưu trữ an toàn và có các hạn chế. OAuth cần xác thực điểm cuối chính xác, xử lý chuyển hướng, xác thực token, thiết kế phạm vi và quyết định loại khách hàng.

OAuth so với OpenID Connect

OAuth cấp phép truy cập vào tài nguyên. Nó không định nghĩa một tuyên bố tiêu chuẩn mà khách hàng có thể coi là danh tính đăng nhập của người dùng. OpenID Connect thêm một lớp xác thực trên OAuth và giới thiệu token ID, một tuyên bố đã ký về sự kiện và chủ thể xác thực.

Khách hàng không nên coi một token truy cập OAuth tùy ý như là bằng chứng đăng nhập. Để đăng nhập, hãy sử dụng một luồng OpenID Connect và xác thực token ID theo siêu dữ liệu và hồ sơ của nhà cung cấp, bao gồm người phát hành, đối tượng, chữ ký, tuyên bố thời gian, nonce khi được sử dụng, và việc ràng buộc phản hồi ủy quyền.

Hướng dẫn Bảo mật OAuth Hiện tại

RFC 9700 cung cấp các thực hành tốt nhất về bảo mật OAuth 2.0 hiện tại.. Nó cập nhật hướng dẫn triển khai dựa trên các cuộc tấn công và kinh nghiệm triển khai. Các hệ thống mới nên sử dụng dòng mã ủy quyền với PKCE, khớp URI chuyển hướng chính xác, tương tác trình duyệt an toàn, và vận chuyển mã thông báo được bảo vệ.

Cấp phát ngầm lộ mã thông báo truy cập qua phản hồi ủy quyền và không phải là thiết kế được ưa chuộng cho các khách hàng mới. Cấp phát chứng chỉ mật khẩu chủ sở hữu tài nguyên yêu cầu một khách hàng xử lý mật khẩu của người dùng và không nên được sử dụng. Những mô hình cũ này có thể xuất hiện trong các hệ thống kế thừa, nhưng sao chép chúng vào một triển khai mới sẽ loại bỏ các ranh giới mạnh mẽ hơn.

Những Sai Lầm Thường Gặp Của OAuth

• Gọi xác thực OAuth. OAuth cho phép truy cập API; sử dụng OpenID Connect cho một lớp danh tính đăng nhập tiêu chuẩn.
• Khớp URI chuyển hướng lỏng lẻo. Chỉ chấp nhận các URI chuyển hướng đã đăng ký chính xác theo quy tắc của hồ sơ.
• Bỏ qua việc xác thực trạng thái. Gắn phản hồi với phiên trình duyệt khởi tạo và từ chối các sự không khớp.
• Bỏ sót PKCE. Các khách hàng mã ủy quyền nên sử dụng một bộ xác minh mới và thử thách an toàn cho mỗi yêu cầu.
• Chấp nhận bất kỳ mã thông báo ký nào. Máy chủ tài nguyên phải xác thực nhà phát hành, đối tượng, loại hoặc hồ sơ, thời gian, chữ ký và các yêu cầu ủy quyền.
• Các phạm vi rộng quá mức. Yêu cầu và phát hành quyền hạn hữu ích nhỏ nhất.
• Đặt mã thông báo vào các URL. Sử dụng tiêu đề ủy quyền qua HTTPS để giảm rò rỉ qua nhật ký và bề mặt trình duyệt.

Trường Hợp Sử Dụng OAuth

Danh Sách Kiểm Tra Triển Khai

1. Chọn cấp phát cho khách hàng và trường hợp sử dụng. Ủy quyền người dùng tương tác và truy cập dịch vụ có các ranh giới niềm tin khác nhau.
2. Đăng ký các URI chuyển hướng chính xác. Tách biệt môi trường và tránh các trình điều hướng chuyển hướng mở.
3. Sử dụng mã ủy quyền với PKCE. Tạo một bộ xác minh và giá trị trạng thái mới cho mỗi yêu cầu ủy quyền.
4. Xác thực mọi phản hồi. Kiểm tra trạng thái, siêu dữ liệu nhà phát hành khi có thể, liên kết mã, và các trường phản hồi mã thông báo.
5. Bảo vệ mã thông báo. Giữ chúng ra khỏi các URL và nhật ký, lưu trữ chúng trong thời gian ngắn nhất cần thiết và sử dụng các mẫu lưu trữ trình duyệt hoặc máy chủ an toàn.
6. Thực thi tại máy chủ tài nguyên. Xác thực hồ sơ mã thông báo, nhà phát hành, đối tượng, thời hạn, phạm vi, và chính sách cấp độ tài nguyên.
7. Lập kế hoạch thu hồi và xử lý sự cố. Người dùng và quản trị viên cần một cách để xóa các ủy quyền và vô hiệu hóa các chứng chỉ bị xâm phạm.

Kết Luận

OAuth tách biệt chứng chỉ chính của người dùng hoặc dịch vụ khỏi các mã thông báo hạn chế mà một khách hàng sử dụng tại một API. Các vai trò, quyền, phạm vi, và điểm cuối của nó tạo ra một ranh giới ủy quyền tiêu chuẩn, nhưng giao thức vẫn phụ thuộc vào việc triển khai chính xác. Mã ủy quyền với PKCE, chuyển hướng chính xác, mã thông báo phát hành hẹp, xác thực máy chủ tài nguyên đúng cách, và OpenID Connect cho đăng nhập cung cấp một nền tảng vững chắc cho các hệ thống hiện tại.