Skip to main content
Hãy sử dụng thông tin xác thực máy khách OAuth khi tích hợp phía backend của Quý khách cần các mã truy cập có thời hạn ngắn hoặc khi chính sách bảo mật của Quý khách yêu cầu như vậy. Mỗi máy khách thuộc về một tài khoản dịch vụ và một tổ chức. OAuth là tùy chọn: một khóa API có phạm vi giới hạn là đủ cho một tích hợp máy chủ riêng có thể lưu trữ và luân chuyển khóa một cách an toàn. Xem Xác thực để chọn giữa hai phương thức và hiểu cách tài khoản dịch vụ phù hợp với từng phương thức.
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.
Cấp quyền thông tin xác thực máy khách đại diện cho tài khoản dịch vụ của Quý khách. Cấp quyền này không đăng nhập một người dùng cũng không yêu cầu khách hàng ủy quyền cho một ứng dụng. Ủy quyền ủy thác thông qua trình duyệt là một khả năng OAuth riêng biệt và không được cung cấp bởi các thao tác này.

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:manage và 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
Ví dụ này thực hiện một yêu cầu và giữ kết quả trong bộ nhớ. Hãy thêm thao tác ghi của trình quản lý bí mật của Quý khách tại điểm được đánh dấu trước khi chạy trong môi trường sản xuất. Ví dụ cố ý yêu cầu một quyết định sau khi có kết quả không xác định thay vì âm thầm tạo một máy khách khác. Các ngoại lệ mạng cũng yêu cầu thực hiện các bước khôi phục bên dưới. Phản hồi tạo và phản hồi biên nhận sử dụng 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.
  • id xác định tài nguyên nền tảng. Hãy lưu lại để truy xuất và thu hồi.
  • client_id xá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à null trong khi việc tạo đang chờ xử lý.
  • client_secret chỉ đượ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.

Luân chuyển mà không mất quyền truy cập

Tạo máy khách thứ hai với giới hạn phạm vi cần thiết. Lưu khóa bí mật của máy khách đó, lấy một mã thông báo bằng điểm cuối mã thông báo theo khu vực của Quý khách, và xác minh rằng tích hợp hoạt động với máy khách đó. Chuyển tích hợp sang máy khách thay thế, sau đó thu hồi tài nguyên cũ. Giữ lại một thông tin xác thực quản lý độc lập để Quý khách có thể khôi phục khi triển khai gặp sự cố. Mã truy cập không thể cấp nhiều hơn các phạm vi của máy khách và các quyền hiện tại của tài khoản dịch vụ. Việc gỡ bỏ quyền của tài khoản hoặc thu hồi máy khách được ưu tiên hơn thời hạn còn lại của mã thông báo. Không coi mã thông báo được lưu trong bộ nhớ đệm là bằng chứng rằng ủy quyền vẫn còn hiệu lực. Hãy lấy mã truy cập mới trước khi hết hạn bằng cách xác thực lại máy khách; cấp quyền này không sử dụng mã thông báo làm mới.