Quyền truy cập OAuth phải được bật cho tổ chức của Quý khách. Quá trình thiết lập sẽ cung cấp
điểm cuối mã thông báo theo khu vực, bên phát hành, đối tượng và phương thức xác thực máy khách.
Nếu Quý khách cần các thiết lập này hoặc không thể truy cập phần quản lý máy khách, vui lòng liên hệ
Bộ phận Hỗ trợ của Living Security.
Trước khi bắt đầu
- Tạo một tài khoản dịch vụ chỉ với các quyền mà tích hợp cần.
- Sử dụng thông tin xác thực quản lý có
service_account:managevà từng quyền mà Quý khách muốn cấp cho máy khách mới. Tài khoản đích cũng phải có các quyền đó. Một máy khách không thể mở rộng thẩm quyền của bất kỳ tài khoản nào. - Chọn khu vực của tổ chức. Thông tin xác thực API và mã truy cập OAuth thuộc về máy chủ API khu vực tương ứng.
- Lưu khóa bí mật của máy khách và các mã thông báo trong kho lưu trữ bí mật phía máy chủ của Quý khách. Tuyệt đối không đặt chúng trong mã trình duyệt, ứng dụng di động, hệ thống quản lý mã nguồn hoặc nhật ký yêu cầu.
Tạo máy khách
POST /v1/oauth_clients yêu cầu service_account_id, một danh sách không rỗng gồm các
scopes tường minh, và một Idempotency-Key. Ký tự đại diện không được chấp nhận. Một máy khách hỗ trợ
tối đa 100 phạm vi, với tổng độ dài tối đa 4,096 ký tự. Mỗi tài khoản
dịch vụ có thể có tối đa 20 máy khách hoặc thao tác tạo/dọn dẹp chưa được giải quyết.
Việc thu hồi sẽ từ chối truy cập API ngay lập tức. Một máy khách hoặc một lần tạo không xác định từ nhà cung cấp
vẫn được tính vào giới hạn cho đến khi việc dọn dẹp từ xa được xác nhận.
Một yêu cầu đặt chỗ bị bỏ dở hoặc một lần tạo được chứng minh là đã thất bại trước khi nhà cung cấp
bắt đầu xử lý có thể giải phóng vị trí của nó một cách an toàn. Khóa thử lại của lần tạo đó vẫn thuộc về
lần thử ban đầu; hãy khôi phục biên nhận đó trước khi quyết định có tạo bản thay thế hay không.
Chọn một khóa thử lại cho lần tạo này và lưu trữ bền vững trước khi gửi
yêu cầu. Sử dụng 1–255 ký tự ASCII hiển thị được, không có khoảng trắng. Dùng lại khóa đó với
cùng tài khoản, phạm vi, chủ thể quản lý, khu vực và phiên bản API sau khi mất phản hồi. Việc luân chuyển thông tin xác thực quản lý thuộc cùng tài khoản dịch vụ
không tạo ra một danh tính thử lại mới.
Cài đặt gói requests của Python. Nạp các giá trị môi trường sau thông qua
quy trình quản lý bí mật và cấu hình thông thường của Quý khách:
Python
201 và chứa tài nguyên oauth_client
với id, service_account_id, client_id, scopes, status, created_at và
client_secret. Các phản hồi được đánh dấu Cache-Control: no-store.
idxác định tài nguyên nền tảng. Hãy lưu lại để truy xuất và thu hồi.client_idxác định máy khách trong quá trình trao đổi mã thông báo. Đây không phải là ID tài nguyên nền tảng. Giá trị này có thể lànulltrong khi việc tạo đang chờ xử lý.client_secretchỉ được trả về cho yêu cầu hoàn tất việc tạo. Mọi yêu cầu tạo lặp lại đều trả vềnull, kể cả yêu cầu thử lại sau khi mất phản hồi thành công. Thao tác truy xuất không bao giờ trả về khóa bí mật.
Khôi phục phản hồi bị mất hoặc bị gián đoạn
Lặp lại cùng yêu cầu tạo với khóa thử lại đã lưu để khôi phục biên nhận tài nguyên. Biên nhận phản ánh trạng thái hiện tại, vì vậy một máy khách đã bị thu hồi vẫn ở trạng thái bị thu hồi. Thao tác này không sử dụng hợp đồng phát lại phản hồi được lưu trong bộ nhớ đệm 24 giờ thông thường và không trả về tiêu đềIdempotent-Replayed.
Xem lỗi để biết ID yêu cầu và chi tiết khôi phục.
Tuyệt đối không gửi khóa bí mật của máy khách hoặc mã truy cập kèm theo yêu cầu hỗ trợ.
Kiểm tra và thu hồi
Sử dụng thông tin xác thực quản lý của Quý khách vàid tài nguyên nền tảng:
Việc thu hồi chặn các yêu cầu API tiếp theo của máy khách, bao gồm cả các yêu cầu dùng
mã thông báo đã được cấp. Việc này không hủy công việc đã được API chấp nhận.
Việc dọn dẹp thông tin xác thực từ xa có thể hoàn tất sau. Lặp lại thao tác thu hồi là an toàn và
không cần khóa thử lại. Hãy tiếp tục sử dụng thông tin xác thực quản lý nếu máy khách
đang bị thu hồi chính là một bên gọi API.

