Google sử dụng công nghệ AI để dịch nội dung sang ngôn ngữ bạn ưu tiên. Bản dịch bằng AI có thể có lỗi.

Sử dụng mã thông báo OAuth của bên thứ ba

Bạn đang xem tài liệu về Apigee Edge.
Truy cập vào tài liệu Apigee X. thông tin

Trong chủ đề này, chúng ta sẽ thảo luận về cách nhập mã truy cập, mã làm mới hoặc mã uỷ quyền do bên ngoài tạo vào kho mã thông báo Edge. Bạn có thể sử dụng kỹ thuật này nếu muốn định cấu hình Apigee Edge để xác thực mã thông báo được tạo bên ngoài Apigee Edge.

Trong trường hợp thông thường, Apigee Edge sẽ tạo và lưu trữ mã thông báo OAuth, đồng thời trả mã thông báo đó về cho ứng dụng gọi. Sau đó, ứng dụng gọi điện sẽ gửi mã thông báo đó trở lại Apigee Edge khi yêu cầu dịch vụ và Apigee Edge (thông qua chính sách OAuthV2 với Operation = VerifyAccessToken) sẽ xác minh rằng mã thông báo đó hợp lệ. Chủ đề này mô tả cách bạn có thể định cấu hình Apigee Edge để lưu trữ mã thông báo OAuth được tạo ở nơi khác, trong khi vẫn giữ nguyên phần xác minh mã thông báo, giống như thể mã thông báo đó do Edge tạo.

Ví dụ

Nếu bạn muốn xem một ví dụ minh hoạ kỹ thuật được mô tả trong chủ đề này, hãy xem mẫu Quản lý mã thông báo được uỷ quyền của Apigee.

Đây là gì?

Giả sử bạn đã có một hệ thống uỷ quyền hiện tại và bạn muốn sử dụng các giá trị mã hoặc mã thông báo do hệ thống đó tạo thay cho các giá trị mã hoặc mã thông báo OAuth2 mà Edge tạo. Sau đó, bạn có thể thực hiện các yêu cầu proxy API an toàn bằng mã thông báo hoặc mã đã thay thế và Edge sẽ xác thực các yêu cầu đó như thể chúng được tạo bởi Edge.

Một số thông tin cơ bản

Trong trường hợp thông thường, Apigee Edge sẽ tạo một mã thông báo bằng cách tạo một chuỗi ngẫu nhiên gồm các chữ cái và số. Apigee Edge liên kết với mã thông báo đó, các dữ liệu khác như thời gian phát hành mã thông báo, thời gian hết hạn, danh sách Sản phẩm API mà mã thông báo hợp lệ và phạm vi. Tất cả thông tin này có thể được trả về trong một phản hồi do chính sách OAuthV2 tự động tạo, được định cấu hình với Operation = GenerateAccessToken. Phản hồi sẽ có dạng như sau:

{
  "issued_at": "1469735625687",
  "application_name": "06947a86-919e-4ca3-ac72-036723b18231",
  "scope": "urn://example.com/read",
  "status": "approved",
  "api_product_list": "[implicit-test]",
  "api_product_list_json": ["implicit-test"],
  "expires_in": "1799", //--in seconds
  "developer.email": "joe@weathersample.com",
  "token_type": "BearerToken",
  "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk",
  "access_token": "zBC90HhCGmGlaMBWeZAai2s3za5j",
  "organization_name": "wwitman",
  "refresh_token_expires_in": "0", //--in seconds
  "refresh_count": "0"
}

Giá trị của thuộc tính access_token thực sự là khoá tra cứu cho dữ liệu phản hồi. Một ứng dụng có thể đưa ra yêu cầu đối với một proxy API được lưu trữ trong Edge, mang mã thông báo của người mang zBC90HhCGmGlaMBWeZAai2s3za5j và Edge (với chính sách OAuthV2 có Thao tác = VerifyAccessToken) sẽ tra cứu mã thông báo, truy xuất tất cả thông tin và sử dụng thông tin đó để xác định xem mã thông báo có hợp lệ hay không cho Proxy API được yêu cầu. Đây được gọi là Xác thực mã thông báo. Tất cả thông tin nêu trên tạo thành mã thông báo. Giá trị access_token chỉ là cách để tra cứu thông tin đó.

Mặt khác, bằng cách làm theo các bước được mô tả ở đây, bạn có thể định cấu hình Edge để lưu trữ một mã thông báo sao cho giá trị access_token của mã thông báo đó là một giá trị do dịch vụ bên ngoài tạo. Tất cả siêu dữ liệu khác có thể giống nhau. Ví dụ: giả sử bạn có một hệ thống bên ngoài Apigee Edge tạo ra các mã thông báo có dạng "TOKEN-<16 số ngẫu nhiên>" . Trong trường hợp đó, siêu dữ liệu đầy đủ của mã thông báo do Apigee Edge lưu trữ có thể là:

{
  "issued_at": "1469735625687",
  "application_name": "06947a86-919e-4ca3-ac72-036723b18231",
  "scope": "urn://example.com/read",
  "status": "approved",
  "api_product_list": "[implicit-test]",
  "api_product_list_json": ["implicit-test"],
  "expires_in": "1799", //--in seconds
  "developer.email": "joe@weathersample.com",
  "token_type": "BearerToken",
  "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk",
  "access_token": "TOKEN-1092837373654221",
  "organization_name": "wwitman",
  "refresh_token_expires_in": "0", //--in seconds
  "refresh_count": "0"
}

Trong trường hợp này, một ứng dụng có thể đưa ra yêu cầu đối với một proxy API được lưu trữ trong Edge, mang mã thông báo của người mang TOKEN-1092837373654221 và Edge (thông qua chính sách OAuthV2 với Thao tác = VerifyAccessToken) sẽ có thể xác thực mã thông báo đó. Bạn có thể áp dụng một mẫu nhập tương tự cho mã uỷ quyền và mã làm mới.

Hãy nói về việc xác thực thông tin đăng nhập của ứng dụng

Một điều kiện tiên quyết để tạo mã thông báo là xác thực ứng dụng khách yêu cầu. Theo mặc định, chính sách OAuthV2/GenerateAccessToken trong Apigee Edge sẽ ngầm xác minh thông tin đăng nhập của ứng dụng khách. Thông thường, trong yêu cầu về mã thông báo OAuthV2, client_id và client_secret được truyền trong tiêu đề Uỷ quyền, được mã hoá thông qua phương thức Uỷ quyền cơ bản của HTTP (nối bằng dấu hai chấm, sau đó mã hoá theo base64). Chính sách OAuthV2/GenerateAccessToken trong Apigee Edge sẽ giải mã tiêu đề đó, tra cứu client_id và xác minh rằng client_secret được truyền vào là hợp lệ cho client_id đó. Điều này sẽ hiệu quả nếu Apigee Edge biết thông tin đăng nhập – nói cách khác, có một Ứng dụng dành cho nhà phát triển được lưu trữ trong Apigee Edge chứa thông tin đăng nhập, bản thân thông tin đăng nhập này chứa client_id và client_secret đã cho.

Trong trường hợp thông tin xác thực ứng dụng không được Apigee Edge xác thực, bạn phải thiết kế API Proxy để xác thực rõ ràng ứng dụng thông qua một số phương tiện khác trước khi API Proxy tạo mã thông báo. Thường thì điều này được thực hiện thông qua chính sách ServiceCallout kết nối với một điểm cuối từ xa trong mạng của bạn.

Dù là cách nào, ngầm hay rõ ràng, bạn cần đảm bảo rằng API Proxy tạo mã thông báo, trước tiên sẽ xác thực thông tin đăng nhập của ứng dụng. Xin lưu ý rằng việc xác thực ứng dụng không phụ thuộc vào việc tạo mã truy cập. Bạn có thể định cấu hình Apigee Edge để thực hiện cả hai, hoặc thực hiện một trong hai, hoặc không thực hiện cả hai.

Nếu bạn muốn chính sách OAuthV2/GenerateAccessToken trong Apigee Edge xác thực thông tin đăng nhập của ứng dụng khách dựa trên kho lưu trữ Edge, hãy đặt phần tử <ExternalAuthorization> thành false trong cấu hình chính sách hoặc bỏ qua hoàn toàn. Nếu bạn muốn dùng một dịch vụ uỷ quyền bên ngoài để xác thực rõ ràng thông tin đăng nhập của ứng dụng, hãy đặt <ExternalAuthorization> thành true.

Mặc dù Apigee Edge có thể không xác thực thông tin đăng nhập của ứng dụng, nhưng ứng dụng vẫn cần biết và được Apigee Edge quản lý client_id. Mọi access_token trong Apigee Edge, cho dù do Apigee Edge tạo hay do một hệ thống bên ngoài tạo rồi nhập vào Apigee Edge, đều phải được liên kết với một ứng dụng khách – được biểu thị bằng client_id. Vì vậy, ngay cả trong trường hợp chính sách OAuthV2/GenerateAccessToken trong Apigee Edge sẽ không xác thực rằng client_id và client_secret khớp nhau, chính sách này sẽ xác thực rằng client_id hợp lệ, hiện tại và chưa bị thu hồi. Vì vậy, trong bước thiết lập bắt buộc, bạn có thể phải nhập client_id thông qua API quản trị Edge.

Luồng chính sách cho OAuth của bên thứ ba trên Apigee

Để sử dụng mã thông báo từ các hệ thống OAuth bên thứ ba trong Apigee Edge, quy trình tạo mã truy cập phải tuân theo một trong các mẫu sau.

Xác thực bên ngoài thông tin đăng nhập của ứng dụng

ServiceCallout để xác minh thông tin đăng nhập của máy khách đến và lấy mã thông báo bên ngoài.
ExtractVariables hoặc bước JavaScript để trích xuất mã thông báo do bên ngoài tạo từ phản hồi.
AssignMessage để đặt biến đặc biệt, nổi tiếng có tên là oauth_external_authorization_status. Giá trị phải là true để cho biết thông tin đăng nhập của ứng dụng khách là hợp lệ.
OAuthV2/GenerateAccessToken với phần tử <ExternalAuthorization> được đặt thành true và ít nhất một trong các phần tử <ExternalAccessToken>, <ExternalRefreshToken> hoặc <ExternalAuthorizationCode>.

Xác thực nội bộ thông tin đăng nhập của ứng dụng

ServiceCallout để lấy mã thông báo bên ngoài.
ExtractVariables hoặc bước JavaScript để trích xuất mã thông báo do bên ngoài tạo từ phản hồi.
OAuthV2/GenerateAccessToken với phần tử <ExternalAuthorization> được đặt thành false và ít nhất một trong các phần tử <ExternalAccessToken>, <ExternalRefreshToken> hoặc <ExternalAuthorizationCode>.

Lưu ý về cấu hình quy trình và chính sách

Trong trường hợp bạn muốn sử dụng một hệ thống bên ngoài để xác thực thông tin đăng nhập của ứng dụng, bạn phải tự phát triển một quy trình chính sách thực hiện những việc cần thiết. Thông thường, bạn sẽ sử dụng chính sách ServiceCallout để gửi thông tin đăng nhập được nhận dạng bên ngoài đến dịch vụ xác thực bên ngoài. Dịch vụ xác thực bên ngoài thường sẽ trả về một phản hồi và nếu thông tin đăng nhập hợp lệ, thì cũng sẽ trả về một mã truy cập.
Sau ServiceCallout, API proxy cần phân tích cú pháp phản hồi để trích xuất trạng thái hợp lệ, cũng như access_token được tạo bên ngoài và có thể là refresh_token.
Trong chính sách OAuthV2/GenerateAccessToken, hãy đặt phần tử <StoreToken> thành true và đặt phần tử <ExternalAuthorization> thành true hoặc false cho phù hợp.

Khi chính sách OAuthV2/GenerateAccessToken thực thi, chính sách này sẽ đọc biến oauth_external_authorization_status. Nếu biến được đặt và giá trị là true, thì Apigee Edge sẽ không cố gắng xác thực thông tin đăng nhập của ứng dụng khách. Nếu bạn không đặt biến này hoặc giá trị không phải là true, thì Apigee Edge sẽ tìm cách xác thực thông tin đăng nhập của ứng dụng khách.
Có 3 phần tử cho chính sách OAuthV2 cho phép bạn chỉ định dữ liệu bên ngoài cần nhập: <ExternalAccessToken>, <ExternalRefreshToken> và <ExternalAuthorizationCode>. Mỗi phần tử trong số này chấp nhận một biến luồng. Chính sách Edge sẽ đọc biến đó để tìm mã truy cập, mã làm mới hoặc mã uỷ quyền do bên ngoài tạo. Bạn phải triển khai các chính sách và logic để đặt mã thông báo hoặc mã bên ngoài vào các biến thích hợp.

Ví dụ: cấu hình sau trong chính sách OAuthV2 yêu cầu Edge tìm mã thông báo trong một biến ngữ cảnh có tên là external_token.
```
<ExternalAccessToken>external_token</ExternalAccessToken>
```
Bạn cũng cần có một bước trước đó để đặt biến đó.
Về việc đặt biến oauth_external_authorization_status, một kỹ thuật phổ biến để đặt biến này là sử dụng chính sách AssignMessage với phần tử AssignVariable, như sau:
```
<AssignMessage name="AssignMessage-SetVariable">
    <DisplayName>Assign Message - Set Variable</DisplayName>
    <AssignVariable>
        <Name>oauth_external_authorization_status</Name>
        <Value>true</Value>
    </AssignVariable>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>
```
Hãy nhớ rằng chính sách này phải nằm trước chính sách OAuthV2 với Operation = GenerateAccessToken.

Ví dụ về chính sách OAuthV2

Chính sách OAuthV2 sau đây sẽ tạo mã truy cập Apigee Edge, giả sử Edge tìm thấy một giá trị mã thông báo trong biến luồng external_access_token.

<OAuthV2 name="OAuth-v20-Store-External-Token">
    <ExternalAccessToken>external_access_token</ExternalAccessToken>
    <ExternalAuthorization>true</ExternalAuthorization>
    <Operation>GenerateAccessToken</Operation>
    <GenerateResponse enabled="true">
        <Format>FORM_PARAM</Format>
    </GenerateResponse>
    <ReuseRefreshToken>false</ReuseRefreshToken>
    <StoreToken>true</StoreToken>
    <SupportedGrantTypes>
        <GrantType>client_credentials</GrantType>
    </SupportedGrantTypes>
    <ExpiresIn ref='flow.variable'>2400000</ExpiresIn>
</OAuthV2>

Thông thường, với loại cấp quyền thông tin đăng nhập của ứng dụng, bạn cần cung cấp một tiêu đề Xác thực cơ bản có Mã ứng dụng khách và Khoá bí mật của ứng dụng đã mã hoá. Tuy nhiên, trong trường hợp này, bạn không cần cung cấp tiêu đề đó. Chính sách này vẫn yêu cầu phải có client_id trong yêu cầu và chính sách sẽ xác thực yêu cầu đó. Edge dự kiến client_id sẽ được gửi dưới dạng một phần của dữ liệu biểu mẫu yêu cầu, ví dụ: trong request.formparam.client_id.

Về lý thuyết, bạn có thể áp dụng mẫu này với bất kỳ dịch vụ uỷ quyền OAuth2 nào của bên thứ ba.