Bearer Token là gì? Truy cập API và xử lý bí mật

Scrapeless Web Unlocker sử dụng một khóa API Scrapeless thông qua phương thức xác thực yêu cầu đã được tài liệu hóa, tách biệt với thông tin xác thực bearer của dịch vụ đích.

Bearer Token là thông tin xác thực dựa trên quyền sở hữu

Bearer token là một thông tin xác thực mà một bên có thể sử dụng bằng cách trình bày chính token đó, mà không cần chứng minh riêng việc sở hữu một khóa mật mã được ràng buộc với token đó. Tiêu chuẩn OAuth bearer token usage định nghĩa thuộc tính này cho truy cập HTTP tới các tài nguyên được bảo vệ. Vì vậy quyền sở hữu là nhạy cảm: người nào có được token hợp lệ có thể có khả năng sử dụng quyền truy cập mà nó mang lại.

Từ bearer không có nghĩa là truy cập không giới hạn. Máy chủ tài nguyên vẫn quyết định liệu token có hợp lệ cho tài nguyên được yêu cầu hay không, liệu nó đã hết hạn hoặc bị thu hồi hay chưa, và liệu thao tác đó có được phép hay không. Một token có thể bị giới hạn trong một phạm vi hẹp và một đối tượng người nhận cụ thể. Bảo vệ bí mật và thực thi các ràng buộc đó là các biện pháp kiểm soát bổ sung cho nhau, không thể thay thế cho nhau.

Một cách dùng quen thuộc là một yêu cầu API có trường Authorization sử dụng sơ đồ Bearer theo sau là thông tin xác thực truy cập. Hãy tuân theo đúng hợp đồng của dịch vụ tài nguyên về vị trí và cách xác thực. Một token được chấp nhận bởi một dịch vụ không nên được giả định là hợp lệ tại dịch vụ khác, ngay cả khi cả hai thuộc cùng một tổ chức hoặc đều cung cấp các endpoint HTTP tương tự.

Bearer, OAuth và JWT mô tả các lớp khác nhau

Bearer mô tả cách sử dụng thông tin xác thực, OAuth mô tả một khuôn khổ ủy quyền, và JWT mô tả một định dạng token có cấu trúc. Các khái niệm này thường xuất hiện cùng nhau nhưng không đồng nghĩa. OAuth có thể phát hành access token được trình bày như thông tin xác thực bearer, và các token đó có thể là chuỗi mờ (opaque) hoặc giá trị có cấu trúc. Client không nên suy ra định dạng của access token chỉ vì nó đến từ OAuth.

Một JWT mang các claim trong một biểu diễn được xác định, với các thuộc tính bảo mật được quyết định bởi cơ chế JOSE đã chọn và các quy tắc xác thực. Đặc tả JSON Web Token không biến mọi JWT thành một OAuth access token. Một khẳng định danh tính, một khẳng định ứng dụng sống ngắn, và một thông tin xác thực truy cập có thể yêu cầu các quy tắc xác thực khác nhau ngay cả khi cách mã hóa của chúng trông giống nhau.

Giải mã token không đồng nghĩa với việc xác thực nó. Các claim có thể đọc được không chứng minh rằng nhà phát hành được tin cậy, rằng cơ chế bảo vệ toàn vẹn là đúng, hoặc rằng máy chủ tài nguyên là đối tượng người nhận dự định. Không bao giờ chấp nhận một token chỉ vì payload của nó có thể được phân tích cú pháp thành JSON. Việc xác thực token phải tuân theo hồ sơ ứng dụng cụ thể và hợp đồng của máy chủ ủy quyền.

Phát hành token và truy cập tài nguyên là các bước tách biệt

Việc phát hành token diễn ra theo chính sách của hệ thống ủy quyền, trong khi truy cập tài nguyên diễn ra khi một dịch vụ đánh giá yêu cầu mang token. Khung OAuth token issuance framework định nghĩa các vai trò và grant để lấy thông tin xác thực truy cập. Nhà cung cấp cũng có thể sử dụng một cơ chế phát hành được tài liệu hóa riêng cho thông tin xác thực của mình. Chính sách chấp nhận của máy chủ tài nguyên phải khớp với bất kỳ cơ chế nào đã tạo ra thông tin xác thực.

Một access token chỉ nên được gửi tới dịch vụ tài nguyên dự định của nó. Một refresh token thuộc về giao diện token của máy chủ ủy quyền và không nên được gửi tới các endpoint nghiệp vụ thông thường. Một client secret xác thực client trong những ngữ cảnh được hỗ trợ và không phải là vật thay thế cho access token tài nguyên của người dùng. Giữ các giá trị này tách biệt giúp ngăn một phiên gỡ lỗi biến thành lộ thông tin xác thực chéo dịch vụ.

Quyết định cấp quyền cũng có thể phụ thuộc vào người dùng hoặc tenant mà token đại diện. Một yêu cầu tới một đối tượng nằm ngoài phạm vi đó phải vẫn bị từ chối ngay cả khi bản thân thông tin xác thực là hợp lệ. Ủy quyền ở cấp đối tượng thuộc về phía máy chủ. Khả năng của client trong việc tạo URL hoặc đoán định danh đối tượng không phải là bằng chứng rằng người gọi được phép đọc đối tượng đó.

Xác thực Bên phát hành, Tài nguyên và Quyền được dự định

Máy chủ tài nguyên cần xác định trạng thái đang hoạt động của thông tin xác thực và mức độ liên quan của nó đối với yêu cầu. Đối với mã thông báo truy cập có cấu trúc, việc này có thể bao gồm kiểm tra bảo vệ tính toàn vẹn, bên phát hành đáng tin cậy, đối tượng dự định, thời gian hiệu lực và các claim ủy quyền. Đối với mã thông báo mờ, máy chủ có thể sử dụng tra cứu nội bộ hoặc một giao diện xác thực được hỗ trợ. Hãy sử dụng hồ sơ của nhà cung cấp thay vì ghép một danh sách kiểm tra chung chung và không đầy đủ vào một trình xác thực tùy chỉnh.

The Cơ chế introspection mã thông báo OAuth xác định một cách để các dịch vụ tài nguyên được bảo vệ truy vấn thông tin về một mã thông báo, bao gồm việc nó có đang hoạt động hay không. Introspection là một tương tác đã được ủy quyền với máy chủ, không phải lời mời các client bất kỳ gửi bí mật đến một trang web giải mã token công khai. Hãy giữ lưu lượng xác thực nằm trong kiến trúc ủy quyền đáng tin cậy.

Một mã thông báo đang hoạt động vẫn có thể không mang quyền cần thiết cho một thao tác cụ thể. Hãy phân biệt tính hợp lệ của mã thông báo với ủy quyền tài nguyên cả trong mã và trong chẩn đoán. Nhật ký đã được làm sạch có thể ghi lại định danh bên phát hành, route, trạng thái và giá trị tương quan yêu cầu mà không lưu lại thông tin xác thực. Điều đó cung cấp bằng chứng hữu ích cho người vận hành mà không khiến người đọc log thừa hưởng quyền truy cập vào các API được bảo vệ.

Bảo vệ Thông tin xác thực Trong Suốt Vòng Đời

Thông tin xác thực kiểu Bearer cần được bảo vệ khi truyền, lưu trữ, sử dụng và loại bỏ. Chỉ gửi chúng qua kết nối an toàn được dự định và giữ chúng khỏi URL trừ khi dịch vụ rõ ràng yêu cầu một tham số kết nối được bảo vệ. URL có thể xuất hiện trong lịch sử trình duyệt, log proxy, phân tích, và ảnh chụp màn hình được chia sẻ. Việc thông tin xác thực có thời hạn ngắn không khiến cho việc lộ lọt bất cẩn trở nên vô hại.

Giữ bí mật khỏi các kho mã nguồn, tệp ví dụ, và telemetry ứng dụng thông thường. Một kho bí mật triển khai có thể đưa thông tin xác thực vào tiến trình cần nó. Hạn chế ai và cái gì có thể đọc giá trị đó, và che đi nó trước khi ghi nhận chẩn đoán yêu cầu. Biến môi trường là cơ chế truyền tải, không phải một chính sách kiểm soát truy cập hay lưu trữ hoàn chỉnh tự thân.

Ứng dụng phía client cần một mô hình đe dọa rõ ràng vì mã chạy trên trình duyệt không thể giữ bí mật cố định vĩnh viễn với người dùng của nó hoặc với các script chạy trong môi trường đó. Một thành phần máy chủ có thể giảm việc lộ token trực tiếp trong một số kiến trúc, nhưng nó cũng đưa vào các yêu cầu riêng về phiên và bảo vệ yêu cầu. Hãy chọn mẫu lưu trữ và phiên dựa trên thiết kế bảo mật của ứng dụng thay vì coi một vị trí lưu trữ là an toàn trong mọi trường hợp.

Diễn giải Thông tin xác thực Bị Từ chối mà Không Phỏng đoán

Một yêu cầu đã xác thực nhưng bị từ chối nên được diễn giải dựa trên trạng thái và trường lỗi đã được tài liệu hóa của endpoint. Thiếu thông tin xác thực hoặc thông tin xác thực không hợp lệ khác với thông tin xác thực hợp lệ nhưng phạm vi không đủ. Hãy giữ những khác biệt đó trong trạng thái kết quả để ứng dụng không trình bày việc bị từ chối quyền như một tập hợp rỗng. Kiểm tra xem dịch vụ nào tạo ra phản hồi trước khi quyết định thông tin xác thực nào cần được chú ý.

Đừng dán một token đang hoạt động vào phiếu hỗ trợ chỉ để chứng minh nó tồn tại. Hãy chia sẻ chi tiết yêu cầu đã được che bớt và sử dụng quy trình hỗ trợ an toàn của nhà cung cấp khi việc điều tra đòi hỏi truy cập tài khoản. Nếu một thông tin xác thực bị lộ, người sở hữu nên tuân theo thủ tục thu hồi hoặc thay thế của bên phát hành và xem xét nơi giá trị đó đã được lưu trữ. Xóa một bản sao cục bộ không loại bỏ những bản sao đã được giữ trong log hoặc các artefact được chia sẻ.

Khi quyền truy cập dựa trên sở hữu là không đủ đối với mô hình đe dọa, các cơ chế ràng buộc người gửi có thể bổ sung yêu cầu bằng chứng. OAuth DPoP ràng buộc việc sử dụng mã thông báo được hỗ trợ với một khóa mật mã và bằng chứng yêu cầu. Đây là một cơ chế được hỗ trợ riêng biệt chứ không chỉ là một header tùy ý bổ sung cho một yêu cầu bearer thông thường. Cả client và dịch vụ đều phải triển khai hợp đồng tương ứng.

Khóa Scrapeless và Target Token Phải Được Tách Biệt

The Các yêu cầu về khóa API Scrapeless quy định phương thức xác thực cho mỗi sản phẩm. Các yêu cầu REST của Web Unlocker sử dụng khóa thô trong x-api-token trường được tài liệu hóa thay vì một sơ đồ Bearer được đoán bừa. Một khóa được truyền qua tham số kết nối trình duyệt cũng là bí mật và cần được che đi khi URL kết nối được ghi log hoặc chia sẻ.

The Các khái niệm xác thực API giúp phân biệt các cơ chế này, trong khi Giá cả Scrapeless liên quan đến việc sử dụng dịch vụ. Một thông tin xác thực tài khoản hợp lệ, một sản phẩm được bật, số dư đủ, và quyền truy cập vào tài nguyên mục tiêu là những điều kiện riêng biệt. Hãy chẩn đoán chúng một cách tách biệt thay vì coi mọi lỗi đều là một chuỗi bearer không đúng định dạng.

Xây dựng Kiểm kê Thông tin xác thực cho Quy trình làm việc

Một kiểm kê thông tin xác thực nên xác định bên phát hành của từng bí mật, bên nhận dự định, các thao tác được phép, vị trí lưu trữ và người sở hữu. Bao gồm hành vi hết hạn hoặc thu hồi nếu nhà cung cấp có quy định. Tránh sao chép giá trị thô vào kiểm kê; thay vào đó hãy mô tả các định danh và tham chiếu tới kho bí mật. Mục tiêu là làm cho ranh giới quyền truy cập trở nên rõ ràng mà không tạo ra một kho mới chứa dữ liệu nhạy cảm.

Đối với một công cụ báo cáo giả định, một thông tin xác thực có thể ủy quyền cho tài khoản dịch vụ dữ liệu riêng của công cụ trong khi một thông tin khác đại diện cho một cấp quyền tài nguyên đã được người dùng phê duyệt. Những giá trị đó cần các đối tượng (audience) và quy tắc hủy bỏ khác nhau. Việc kiểm thử cần xác nhận rằng thông tin xác thực không đúng sẽ bị từ chối và nhật ký vẫn được làm sạch. Một bảng kiểm kê rõ ràng giúp việc duy trì sự tách biệt đó dễ dàng hơn khi nhiều nhà cung cấp được thêm vào quy trình làm việc.

Kết luận

Một bearer token rất mạnh vì chỉ cần sở hữu là đủ để trình bày quyền truy cập của nó. Hãy giữ rõ ràng về bên phát hành, bên nhận dự kiến, phạm vi quyền hạn và ranh giới lưu trữ, và xác thực thông tin xác thực bằng hợp đồng token thực tế của dịch vụ. Tách biệt các access token cho mục tiêu với khóa API của nền tảng để một tích hợp không làm lộ quyền hạn vốn dành cho một tích hợp khác.