Mọi nhóm API đều gặp phải cùng một vấn đề. Các điểm cuối hoạt động độc lập, sau đó ai đó bật OAuth 2.0 và một nửa bộ thử nghiệm bắt đầu trả về lỗi 401. Đột nhiên bạn phải xử lý các máy chủ ủy quyền, mã thông báo truy cập có thời hạn ngắn và phạm vi, và việc sao chép mã thông báo thủ công từ phản hồi curl vào trường tiêu đề trở nên nhàm chán sau lần chạy thứ ba.
Giải pháp không phải là bỏ qua xác thực trong các thử nghiệm của bạn. Mà là biến việc xử lý mã thông báo thành một phần của thiết lập thử nghiệm để nó không còn là công việc thủ công. Hướng dẫn này bao gồm hai luồng bạn sẽ gặp trong hầu hết mọi kế hoạch thử nghiệm: luồng mã ủy quyền OAuth (với PKCE) cho các API hoạt động thay mặt người dùng và luồng thông tin xác thực máy khách cho các cuộc gọi từ máy sang máy. Nếu bạn muốn có cái nhìn tổng quan đầy đủ về các loại cấp quyền trước, bài tổng quan về các luồng OAuth 2.0 của chúng tôi sẽ hướng dẫn bạn qua tất cả chúng.
Sau đó, chúng ta sẽ bắt tay vào thực hành: cấu hình xác thực OAuth 2.0 trong Apidog, lấy mã thông báo một lần và tái sử dụng nó trên nhiều yêu cầu, để các mã thông báo hết hạn tự động làm mới, kế thừa xác thực ở cấp độ thư mục và kiểm tra các đường dẫn lỗi mà đánh giá bảo mật của bạn sẽ yêu cầu.
Hai luồng quan trọng trong kiểm thử API
OAuth 2.0 định nghĩa một số loại cấp quyền, nhưng đối với kiểm thử API hàng ngày, bạn sẽ dành phần lớn thời gian với hai trong số đó. Chọn dựa trên một câu hỏi: API hoạt động thay mặt cho người dùng hay thay mặt cho một dịch vụ?
Luồng mã ủy quyền, với PKCE
Luồng mã ủy quyền là cách tiêu chuẩn để lấy một mã thông báo gắn với người dùng. Máy khách gửi người dùng đến máy chủ ủy quyền, người dùng đăng nhập và đồng ý, máy chủ chuyển hướng trở lại với một mã dùng một lần, và máy khách đổi mã đó lấy mã thông báo truy cập tại điểm cuối mã thông báo. RFC 6749 định nghĩa toàn bộ quá trình này trong phần 4.1.
PKCE (Proof Key for Code Exchange, RFC 7636) củng cố quá trình trao đổi. Máy khách tạo một trình xác minh ngẫu nhiên, gửi một thử thách đã được băm cùng với yêu cầu ủy quyền, sau đó chứng minh rằng nó giữ trình xác minh gốc khi đổi mã. Kẻ tấn công chặn mã sẽ không thể sử dụng được. PKCE ban đầu là một bản sửa lỗi cho ứng dụng di động, nhưng hướng dẫn hiện tại từ oauth.net khuyến nghị sử dụng nó cho mọi trao đổi mã ủy quyền, bao gồm cả máy khách bảo mật.
Thử nghiệm với luồng này bất cứ khi nào hành vi của điểm cuối phụ thuộc vào người dùng là ai: GET /orders chỉ trả về các đơn đặt hàng của người gọi, các điểm cuối quản trị giới hạn theo vai trò, giới hạn tốc độ theo từng người dùng.
Luồng thông tin xác thực máy khách
Loại cấp quyền thông tin xác thực máy khách OAuth 2.0 bỏ qua hoàn toàn người dùng. Máy khách xác thực bằng ID và bí mật của chính nó và nhận một mã thông báo đại diện cho chính ứng dụng. Một yêu cầu POST đến điểm cuối mã thông báo, không có trình duyệt, không chuyển hướng:
curl -X POST https://auth.example.com/oauth/token \
-d grant_type=client_credentials \
-d client_id=orders_service \
-d client_secret=s3cr3t_value \
-d scope="orders:read orders:write"
Đây là luồng dành cho các API từ máy sang máy: microservice nội bộ, các tác vụ cron, các pipeline CI gọi API triển khai. Đây cũng là công cụ chính của kiểm thử tự động, vì nó không cần có con người tham gia. Nếu môi trường thử nghiệm của bạn cho phép bạn cung cấp một máy khách thử nghiệm, hãy sử dụng thông tin xác thực máy khách cho mọi thứ trừ các trường hợp mà danh tính người dùng là đối tượng kiểm thử.
Cấu hình xác thực OAuth 2.0 trong Apidog
Apidog coi OAuth 2.0 là một loại xác thực ưu việt. Bạn cấu hình nó một lần, trong tab Auth của một yêu cầu hoặc thư mục, và nền tảng sẽ xử lý việc tìm nạp, đính kèm và làm mới mã thông báo. Các loại cấp quyền được hỗ trợ bao gồm Authorization Code, Authorization Code (With PKCE), Client Credentials, Password Credentials và Implicit.
Dưới đây là thiết lập cho hai luồng trên, sử dụng một API quản lý đơn hàng hư cấu.
Thiết lập thông tin xác thực máy khách
Mở yêu cầu (hoặc tốt hơn là thư mục; chi tiết hơn ở dưới), chuyển loại xác thực sang OAuth 2.0 và chọn Client Credentials làm loại cấp quyền. Điền vào:
- URL Mã thông báo truy cập:
https://auth.example.com/oauth/token - ID máy khách:
orders_service - Bí mật máy khách: bí mật đã được cung cấp của bạn
- Phạm vi:
orders:read orders:write(đặt trong các tùy chọn nâng cao)
Apidog cung cấp cho bạn hai cách để gửi thông tin xác thực: dưới dạng tiêu đề Basic Auth hoặc trong phần thân yêu cầu. Hãy khớp với những gì máy chủ ủy quyền của bạn mong đợi; Auth0 và Okta chấp nhận cả hai, nhưng một số máy chủ nội bộ chỉ phân tích cú pháp phần thân.
Nhấp vào Lấy mã thông báo. Apidog gọi điểm cuối mã thông báo, lưu trữ kết quả và hiển thị mã thông báo cùng với thời gian hiệu lực của nó. Kể từ đó, mỗi lần gửi sẽ đính kèm nó vào tiêu đề Authorization với tiền tố Bearer. Không sao chép-dán, không cần xử lý biến {{token}}.
Thiết lập mã ủy quyền với PKCE
Để kiểm thử theo ngữ cảnh người dùng, hãy chọn Authorization Code (With PKCE) làm loại cấp quyền. PKCE là một tùy chọn cấp quyền riêng trong Apidog, không phải là một hộp kiểm. Bạn sẽ cần thêm một vài trường:
- URL Xác thực:
https://auth.example.com/oauth/authorize - URL Mã thông báo truy cập:
https://auth.example.com/oauth/token - URL Callback: URI chuyển hướng đã đăng ký với nhà cung cấp của bạn
- ID máy khách và Bí mật máy khách: từ đăng ký ứng dụng OAuth của bạn
Nhấp vào Lấy mã thông báo và Apidog mở một cửa sổ trình duyệt trỏ đến trang đăng nhập. Đăng nhập với tư cách người dùng thử nghiệm của bạn, chấp thuận màn hình đồng ý, và mã thông báo sẽ trở lại và nằm trong cùng một vị trí được quản lý như trước. Nếu nhà cung cấp của bạn trả về mã thông báo ID OpenID Connect cùng với mã thông báo truy cập, tùy chọn Token Type Used cho phép bạn chuyển đổi mã nào được đính kèm; hữu ích khi API đang kiểm thử xác thực mã thông báo ID.
Một mẹo thực tế: hãy giữ một người dùng thử nghiệm chuyên dụng cho mỗi vai trò bạn cần kiểm tra (người mua, quản trị viên, kiểm toán viên chỉ đọc). Lấy mã thông báo dưới mỗi người dùng và chạy lại cùng một kịch bản là cách nhanh nhất để xác minh các quy tắc truy cập dựa trên vai trò.
Tái sử dụng và tự động làm mới mã thông báo
Mã thông báo truy cập thường hết hạn trong vòng một giờ. Trước khi Apidog xử lý điều này, một mã thông báo hết hạn có nghĩa là một lần chạy thất bại và phải lấy lại thủ công, đây chính là loại lỗi không ổn định mà các nhóm thường bỏ qua.
Giờ đây, Apidog tự động làm mới mã thông báo OAuth 2.0 khi máy chủ ủy quyền cấp một mã thông báo làm mới, một tính năng đã được phát hành trong bản cập nhật tháng Sáu. Khi mã thông báo truy cập đã lưu trữ hết hạn, Apidog sử dụng mã thông báo làm mới để lấy mã thông báo mới và thay thế nó trước khi gửi. Bạn cũng có thể trỏ nó đến một URL mã thông báo làm mới tùy chỉnh trong cài đặt nâng cao nếu nhà cung cấp của bạn tách biệt hai điểm cuối.
Đối với thông tin xác thực máy khách, nhiều máy chủ bỏ qua hoàn toàn mã thông báo làm mới (đặc tả cho phép điều đó, vì máy khách có thể xác thực lại bất cứ lúc nào). Trong thực tế điều này không gây hại: việc lấy lại bằng Lấy mã thông báo chỉ là một cú nhấp chuột, và các lần chạy theo lịch trình hoặc CI có thể yêu cầu một mã thông báo mới khi bắt đầu mỗi lần chạy.
Kế thừa xác thực ở cấp độ thư mục
Cấu hình OAuth trên mỗi yêu cầu là không hiệu quả. Apidog cho phép bạn đặt xác thực trên một thư mục, và các yêu cầu bên trong nó sẽ kế thừa cấu hình từ thư mục cha. Đặt OAuth 2.0 một lần trên thư mục “Orders API” của bạn và mọi yêu cầu bên dưới nó, bao gồm cả những yêu cầu mới mà đồng đội của bạn thêm vào sprint tiếp theo, sẽ gửi cùng một mã thông báo được quản lý.
Điều này quan trọng nhất trong các kịch bản kiểm thử nhiều bước. Một kịch bản thanh toán có thể liên kết POST /carts, POST /carts/{id}/items và POST /orders. Với xác thực cấp thư mục, cả ba bước đều chia sẻ một mã thông báo và một cấu hình. Khi mã thông báo hết hạn giữa kịch bản, việc tự động làm mới sẽ xử lý. Và khi nhóm bảo mật của bạn thay đổi bí mật máy khách, bạn cập nhật một thư mục thay vì bốn mươi yêu cầu.
Các yêu cầu vẫn giữ tùy chọn ghi đè cấu hình cha, đây chính xác là điều bạn muốn cho các thử nghiệm tiêu cực. Chúng ta sẽ nói thêm về điều đó ngay bây giờ.
Kiểm thử các đường dẫn lỗi
Các thử nghiệm OAuth theo luồng thành công chứng minh đường ống mã thông báo của bạn hoạt động. Các thử nghiệm theo luồng lỗi chứng minh API của bạn thực thi xác thực. Bỏ qua chúng và bạn đang tin tưởng vào các giá trị mặc định của framework. Dưới đây là ba trường hợp đáng để tự động hóa; để nhắc lại về ý nghĩa của từng mã trạng thái, hãy xem bài so sánh của chúng tôi về khóa API và mã thông báo bearer.
Mã thông báo hết hạn hoặc bị thiếu: mong đợi 401
Sao chép một yêu cầu trong kịch bản của bạn và ghi đè xác thực kế thừa của nó bằng cách không xác thực hoặc bằng một mã thông báo bearer đã được mã hóa cứng, không còn hiệu lực, ví dụ Bearer expired_token_do_not_rotate. Khẳng định về:
- Mã trạng thái bằng
401 - Tiêu đề phản hồi
WWW-Authenticatephải có mặt (RFC 6749's companion, RFC 6750, mong đợi điều này) - Phần thân không làm lộ vết ngăn xếp hoặc tên máy chủ nội bộ
Mã 200 ở đây là một lỗi nghiêm trọng. Mã 403 là một dấu hiệu thiết kế đáng để tạo một phiếu: máy chủ nên phân biệt “Tôi không biết bạn là ai” với “Tôi biết bạn, nhưng không cho phép.”
Phạm vi sai: mong đợi 403
Cung cấp một máy khách thử nghiệm thứ hai giới hạn ở orders:read, lấy mã thông báo của nó và gọi một điểm cuối ghi như POST /orders. Khẳng định trạng thái là 403 và, nếu API của bạn tuân theo RFC 6750, tiêu đề WWW-Authenticate bao gồm error="insufficient_scope". Thử nghiệm này bắt lỗi cấu hình sai kinh điển khi các phạm vi được kiểm tra tại gateway cho một số tuyến đường và bị bỏ quên ở những tuyến khác. Nếu các phạm vi còn mới đối với nhóm của bạn, bài giải thích về phạm vi OAuth 2.0 sẽ đề cập cách phân chia chúng.
Máy khách không hợp lệ: mong đợi một lỗi điểm cuối mã thông báo rõ ràng
Trỏ một yêu cầu trực tiếp đến https://auth.example.com/oauth/token với client_secret giả mạo. Theo RFC 6749 phần 5.2, máy chủ nên trả về 400 (hoặc 401 cho xác thực máy khách không thành công) với phần thân JSON chứa "error": "invalid_client". Khẳng định cả hai. Máy chủ ủy quyền cũng là API và hợp đồng lỗi của chúng là một phần bề mặt của bạn.
Khẳng định trên phản hồi mã thông báo trong các kịch bản kiểm thử
Điểm cuối mã thông báo xứng đáng được kiểm tra riêng, ngoài trường hợp máy khách không hợp lệ. Thêm một bước vào kịch bản kiểm thử của bạn để gọi trực tiếp điểm cuối mã thông báo, sau đó đính kèm các khẳng định vào phản hồi:
access_tokentồn tại và không rỗngtoken_typebằngbearer(không phân biệt chữ hoa chữ thường theo đặc tả)expires_inlớn hơn 0 và nằm trong chính sách của bạn, ví dụ không quá 3600scopekhớp với những gì đã yêu cầu, phát hiện các máy chủ âm thầm thu hẹp quyền cấp
Các kịch bản kiểm thử của Apidog cho phép bạn thêm các khẳng định này dưới dạng trực quan trên JSON phản hồi, không yêu cầu viết kịch bản, và bạn có thể trích xuất access_token vào một biến cho một bước tiếp theo khi bạn muốn kiểm thử quá trình bắt tay thô thay vì sử dụng xác thực được quản lý. Tích hợp kịch bản này vào quá trình chạy CI của bạn và một máy chủ ủy quyền hoạt động không đúng sẽ làm lỗi bản dựng thay vì xuất hiện dưới dạng lỗi 401 bí ẩn trong môi trường sản phẩm.
Vòng lặp đầy đủ trông như sau: cấu hình OAuth 2.0 cấp thư mục cho luồng thành công, ghi đè từng yêu cầu cho các trường hợp 401 và 403, và một kịch bản kiểm tra mạnh mẽ hợp đồng của điểm cuối mã thông báo. Điều này bao gồm các API ngữ cảnh người dùng thông qua mã ủy quyền với PKCE và các API từ dịch vụ đến dịch vụ thông qua thông tin xác thực máy khách, với việc làm mới mã thông báo được xử lý cho bạn. Tải xuống Apidog và dùng thử miễn phí; loại xác thực OAuth 2.0 hoạt động trên gói miễn phí, vì vậy bạn có thể trỏ nó đến điểm cuối mã thông báo của riêng mình chỉ trong vài phút.
Câu hỏi thường gặp
Tôi nên sử dụng luồng OAuth nào để kiểm thử API?
Sử dụng thông tin xác thực máy khách cho mọi thứ từ máy sang máy và cho hầu hết các bộ tự động hóa, vì nó không cần tương tác trình duyệt. Sử dụng luồng mã ủy quyền với PKCE khi thử nghiệm phụ thuộc vào danh tính người dùng: cách ly dữ liệu theo người dùng, kiểm tra vai trò hoặc hành vi đồng ý. Tránh các cấp quyền implicit và password trong các kế hoạch thử nghiệm mới; cả hai đều không được khuyến khích trong hướng dẫn OAuth hiện tại.
Làm cách nào để tự động làm mới mã thông báo đã hết hạn trong Apidog?
Cấu hình OAuth 2.0 trong tab Auth và lấy mã thông báo bằng Lấy mã thông báo. Khi máy chủ ủy quyền trả về mã thông báo làm mới, Apidog sẽ làm mới mã thông báo truy cập khi hết hạn mà bạn không cần xác thực lại, và bạn có thể đặt URL mã thông báo làm mới riêng trong cài đặt nâng cao nếu nhà cung cấp của bạn sử dụng. Đối với các thiết lập thông tin xác thực máy khách không có mã thông báo làm mới, việc chạy lại Lấy mã thông báo sẽ cấp một mã thông báo mới.
Mọi yêu cầu trong một kịch bản có thể chia sẻ một mã thông báo OAuth không?
Có. Đặt cấu hình OAuth 2.0 trên thư mục cha và các yêu cầu bên trong sẽ kế thừa nó, do đó một kịch bản nhiều bước chạy dưới một mã thông báo được quản lý duy nhất. Các yêu cầu riêng lẻ vẫn có thể ghi đè cấu hình thư mục, đây là cách bạn đưa các thử nghiệm tiêu cực (mã thông báo hết hạn, phạm vi sai) vào cùng một kịch bản.
Mã 401 so với 403 nên có ý nghĩa gì trong các API được bảo vệ bằng OAuth?
Trả về 401 khi xác thực thất bại: mã thông báo bị thiếu, hết hạn hoặc bị lỗi. Trả về 403 khi mã thông báo hợp lệ nhưng thiếu quyền, chẳng hạn như thiếu phạm vi. Trộn lẫn chúng sẽ làm hỏng logic thử lại của máy khách, vì 401 yêu cầu máy khách xác thực lại trong khi 403 yêu cầu nó dừng lại. Hướng dẫn của chúng tôi về kiểm thử xác thực JWT đi sâu vào việc xác thực chính mã thông báo.