Bạn đang xem tài liệu về Apigee Edge.
Chuyển đến tài liệu về
Apigee X. thông tin
Nội dung
OAuthV2 là một chính sách đa chiều để thực hiện các thao tác cấp quyền sử dụng OAuth 2.0. Đây là chính sách chính dùng để định cấu hình điểm cuối OAuth 2.0 trên Apigee Edge.
Mẹo: Nếu bạn muốn tìm hiểu thêm về OAuth trên Apigee Edge, hãy xem trang chủ OAuth. Trang này cung cấp đường liên kết đến các tài nguyên, đoạn nhạc, video và nhiều nội dung khác. Hãy xem mẫu OAuth nâng cao trên GitHub để thấy minh hoạ rõ ràng về cách sử dụng chính sách này trong một ứng dụng đang hoạt động.
Mẫu
VerifyAccessToken
VerifyAccessToken
Cấu hình chính sách OAuthV2 này (với thao tác VerifyAccessToken) xác minh rằng một mã truy cập được gửi đến Apigee Edge là hợp lệ. Khi thao tác chính sách này được kích hoạt, Edge sẽ tìm kiếm một mã truy cập hợp lệ trong yêu cầu. Nếu mã truy cập hợp lệ, yêu cầu sẽ được phép tiếp tục. Nếu không hợp lệ, mọi quá trình xử lý sẽ dừng và hệ thống sẽ trả về lỗi trong phản hồi.
<OAuthV2 async="false" continueOnError="false" enabled="true" name="OAuth-v20-2"> <DisplayName>OAuth v2.0 2</DisplayName> <Operation>VerifyAccessToken</Operation> <AccessTokenPrefix>Bearer</AccessTokenPrefix> <!-- Optional, default is Bearer --> </OAuthV2>
Lưu ý: Chỉ hỗ trợ mã thông báo mang OAuth 2.0. Không hỗ trợ mã thông báo Mã xác thực thư (MAC).
Ví dụ:
$ curl -H "Authorization: Bearer ylSkZIjbdWybfsUQe9BqP0LH5Z" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282
Theo mặc định, Edge chấp nhận mã truy cập trong tiêu đề Authorization
có tiền tố Bearer
. Bạn có thể thay đổi giá trị mặc định này bằng phần tử <AccessToken>
.
GenerateAccessToken
Đang tạo mã truy cập
Để xem ví dụ minh hoạ cách yêu cầu mã truy cập cho từng loại cấp quyền được hỗ trợ, hãy xem phần Yêu cầu mã truy cập và mã uỷ quyền. Chủ đề bao gồm ví dụ về các thao tác này:
GenerateAuthorizationCode
Tạo mã uỷ quyền
Để xem ví dụ minh hoạ cách yêu cầu mã uỷ quyền, hãy xem bài viết Yêu cầu mã uỷ quyền.
RefreshAccessToken
Làm mới mã truy cập
Để biết ví dụ minh hoạ cách yêu cầu mã truy cập bằng mã làm mới, hãy xem phần Làm mới mã truy cập.
Mã thông báo luồng phản hồi
Tạo mã truy cập trên luồng phản hồi
Đôi khi, bạn có thể cần tạo mã truy cập trong quy trình phản hồi. Ví dụ: bạn có thể thực hiện việc này để phản hồi một số phương thức xác thực tuỳ chỉnh được thực hiện trong một dịch vụ phụ trợ. Trong ví dụ này, trường hợp sử dụng yêu cầu cả mã truy cập và mã làm mới, loại trừ loại cấp quyền ngầm ẩn. Trong trường hợp này, chúng ta sẽ sử dụng kiểu cấp mật khẩu để tạo mã thông báo. Như bạn thấy, mẹo để thực hiện công việc này là chuyển tiêu đề Yêu cầu uỷ quyền có chính sách JavaScript.
Trước tiên, hãy xem chính sách mẫu:
<OAuthV2 enabled="true" continueOnError="false" async="false" name="generateAccessToken"> <Operation>GenerateAccessToken</Operation> <AppEndUser>Doe</AppEndUser> <UserName>jdoe</UserName> <PassWord>jdoe</PassWord> <GrantType>grant_type</GrantType> <ClientId>a_valid_client_id</ClientId> <SupportedGrantTypes> <GrantType>password</GrantType> </SupportedGrantTypes> </OAuthV2>
Nếu bạn đặt chính sách này vào quy trình phản hồi, thì hệ thống sẽ không thực hiện được lỗi với lỗi 401 UnAuthorized (Không được phép) mặc dù chính sách này đã chỉ định thông số đăng nhập chính xác. Để giải quyết vấn đề này, bạn cần đặt tiêu đề Yêu cầu uỷ quyền.
Tiêu đề Uỷ quyền phải chứa một Lược đồ truy cập cơ bản với client_id:client_secret được mã hoá Base64.
Bạn có thể thêm tiêu đề này bằng chính sách JavaScript được đặt ngay trước chính sách OAuthV2, như sau. Các biến "local_clientid" và "local_secret" phải được đặt trước và có sẵn trong quy trình:
var client_id = context.getVariable("local_clientid"); var client_secret = context.getVariable("local_secret"); context.setVariable("request.header.Authorization","Basic "+CryptoJS.enc.Base64.stringify(CryptoJS.enc.Latin1 .parse(client_id + ':' + client_secret)));
Hãy xem thêm phần "Mã hoá thông tin xác thực cơ bản".
Tham chiếu phần tử
Tài liệu tham khảo về chính sách mô tả các phần tử và thuộc tính của chính sách OAuthV2.
Chính sách mẫu được hiển thị bên dưới là một trong nhiều cấu hình có thể có. Mẫu này cho thấy một chính sách OAuthV2 được định cấu hình cho tác vụ GenerateAccessToken. Trong đó có cả các phần tử bắt buộc và không bắt buộc. Hãy tham khảo nội dung mô tả phần tử trong phần này để biết thông tin chi tiết.
<OAuthV2 name="GenerateAccessToken"> <!-- This policy generates an OAuth 2.0 access token using the client_credentials grant type --> <Operation>GenerateAccessToken</Operation> <!-- This is in millseconds, so expire in an hour --> <ExpiresIn>3600000</ExpiresIn> <SupportedGrantTypes> <GrantType>client_credentials</GrantType> </SupportedGrantTypes> <GrantType>request.queryparam.grant_type</GrantType> <GenerateResponse/> </OAuthV2>
Thuộc tính < OAuthV2>
<OAuthV2 async="false" continueOnError="false" enabled="true" name="MyOAuthPolicy">
Bảng sau đây mô tả các thuộc tính chung cho tất cả phần tử mẹ của chính sách:
Thuộc tính | Nội dung mô tả | Mặc định | Sự hiện diện |
---|---|---|---|
name |
Tên nội bộ của chính sách. Giá trị của thuộc tính Nếu muốn, bạn có thể sử dụng phần tử |
Không áp dụng | Bắt buộc |
continueOnError |
Đặt thành Đặt thành |
false | Không bắt buộc |
enabled |
Đặt thành Đặt thành |
đúng | Không bắt buộc |
async |
Thuộc tính này không được dùng nữa. |
false | Không được dùng nữa |
Phần tử <DisplayName>
Sử dụng cùng với thuộc tính name
để gắn nhãn cho chính sách trong trình chỉnh sửa proxy giao diện người dùng quản lý bằng tên khác theo ngôn ngữ tự nhiên.
<DisplayName>Policy Display Name</DisplayName>
Mặc định |
Không áp dụng Nếu bạn bỏ qua phần tử này, thì giá trị thuộc tính |
---|---|
Sự hiện diện | Không bắt buộc |
Loại | Chuỗi |
Phần tử <AccessToken>
<AccessToken>request.header.access_token</AccessToken>
Theo mặc định, VerifyAccessToken dự kiến sẽ gửi mã truy cập trong tiêu đề Authorization
.
Bạn có thể thay đổi giá trị mặc định đó bằng phần tử này. Ví dụ: request.queryparam.access_token
cho biết mã truy cập phải hiển thị dưới dạng tham số truy vấn có tên access_token
.
<AccessToken>request.header.access_token</AccessToken>
được chỉ định:
curl https://myorg-myenv.apigee.net/oauth2/validate -H "access_token:Rft3dqrs56Blirls56a"Ví dụ trong đó
<AccessToken>request.queryparam.access_token</AccessToken>
được chỉ định:
curl "https://myorg-myenv.apigee.net/oauth2/validate?access_token:Rft3dqrs56Blirls56a"
Mặc định: |
Không áp dụng |
Sự hiện diện: |
Không bắt buộc |
Loại: | Chuỗi |
Dùng với các toán tử: |
|
Phần tử <AccessTokenPrefix>
<AccessTokenPrefix>Bearer</AccessTokenPrefix>
Theo mặc định, VerifyAccessToken dự kiến rằng mã truy cập sẽ được gửi trong tiêu đề Uỷ quyền dưới dạng mã thông báo mang tên ( Bearer). Ví dụ:
-H "Authorization: Bearer Rft3dqrs56Blirls56a"
Hiện tại, Bearer là tiền tố duy nhất được hỗ trợ.
Mặc định: |
Sóng mang |
Sự hiện diện: |
Không bắt buộc |
Loại: | Chuỗi |
Giá trị hợp lệ: |
Sóng mang |
Dùng với các toán tử: |
|
Phần tử <AppEndUser>
<AppEndUser>request.queryparam.app_enduser</AppEndUser>
Trong trường hợp phải gửi mã nhận dạng người dùng cuối của ứng dụng đến máy chủ uỷ quyền, phần tử này sẽ cho phép bạn chỉ định nơi Edge nên tìm mã nhận dạng người dùng cuối. Ví dụ: sự kiện này có thể được gửi dưới dạng tham số truy vấn hoặc trong tiêu đề HTTP.
Ví dụ: request.queryparam.app_enduser
cho biết rằng AppEndUser phải hiển thị dưới dạng tham số truy vấn, chẳng hạn như ?app_enduser=ntesla@theramin.com
. Chẳng hạn, để yêu cầu AppEndUser trong tiêu đề HTTP, hãy đặt giá trị này thành request.header.app_enduser
.
Khi cung cấp chế độ cài đặt này, bạn có thể đưa mã nhận dạng người dùng cuối của ứng dụng vào mã truy cập. Tính năng này hữu ích nếu bạn muốn truy xuất hoặc thu hồi mã truy cập OAuth 2.0 theo mã nhận dạng người dùng cuối. Để biết thêm thông tin, hãy xem phần Bật tính năng truy xuất và thu hồi mã truy cập OAuth 2.0 theo mã người dùng cuối, mã ứng dụng hoặc cả hai.
Mặc định: |
Không áp dụng |
Sự hiện diện: |
Không bắt buộc |
Loại: | Chuỗi |
Giá trị hợp lệ: |
Bất kỳ biến luồng nào có thể truy cập được vào chính sách trong thời gian chạy. |
Được dùng với các loại quyền: |
|
<Thuộc tính/Thuộc tính>
<Attributes> <Attribute name="attr_name1" ref="flow.variable" display="true|false">value1</Attribute> <Attribute name="attr_name2" ref="flow.variable" display="true|false">value2</Attribute> </Attributes>
Sử dụng phần tử này để thêm thuộc tính tuỳ chỉnh vào mã truy cập hoặc mã uỷ quyền. Ví dụ: bạn nên nhúng mã nhận dạng người dùng hoặc giá trị nhận dạng phiên vào một mã truy cập mà bạn có thể trích xuất và kiểm tra trong thời gian chạy.
Phần tử này cho phép bạn chỉ định giá trị trong biến luồng hoặc từ một chuỗi giá trị cố định. Nếu bạn chỉ định cả biến và chuỗi, thì giá trị được chỉ định trong biến luồng sẽ được sử dụng. Nếu biến không thể phân giải được, thì chuỗi sẽ là giá trị mặc định.
Để biết thêm thông tin về cách sử dụng phần tử này, hãy xem bài viết Tuỳ chỉnh mã thông báo và Mã uỷ quyền.
Hiện hoặc ẩn thuộc tính tuỳ chỉnh trong phản hồi
Hãy nhớ rằng nếu bạn đặt phần tử GenerateResponse của chính sách này thành true, thì giá trị biểu thị JSON đầy đủ của mã thông báo sẽ được trả về trong phản hồi, bao gồm mọi thuộc tính tuỳ chỉnh mà bạn đặt. Trong một số trường hợp, bạn nên ẩn một số hoặc tất cả thuộc tính tuỳ chỉnh trong phản hồi để các ứng dụng khách không nhìn thấy những thuộc tính đó.
Theo mặc định, các thuộc tính tuỳ chỉnh sẽ xuất hiện trong câu trả lời. Nếu muốn ẩn các quảng cáo này, bạn có thể đặt tham số display thành false. Ví dụ:
<Attributes> <Attribute name="employee_id" ref="employee.id" display="false"/> <Attribute name="employee_name" ref="employee.name" display="false"/> </Attributes>
Giá trị của thuộc tính display
không được duy trì. Giả sử bạn tạo một mã truy cập có các thuộc tính tuỳ chỉnh mà bạn muốn ẩn trong phản hồi đã tạo. Việc đặt display=false
sẽ giúp bạn hoàn thành mục tiêu đó. Tuy nhiên, nếu sau đó một mã truy cập mới được tạo bằng mã làm mới, thì các thuộc tính tuỳ chỉnh ban đầu của mã truy cập đó sẽ xuất hiện trong phản hồi của mã làm mới. Điều này là do Edge không nhớ rằng ban đầu, thuộc tính display
được đặt thành false
trong chính sách tạo mã truy cập. Thuộc tính tuỳ chỉnh này chỉ là một phần trong siêu dữ liệu của mã truy cập.
Bạn sẽ thấy hành vi tương tự nếu thêm các thuộc tính tuỳ chỉnh vào mã uỷ quyền. Khi một mã truy cập được tạo bằng mã đó, các thuộc tính tuỳ chỉnh đó sẽ xuất hiện trong phản hồi của mã truy cập. Xin nhắc lại rằng đây có thể không phải là hành vi bạn mong muốn.
Để ẩn thuộc tính tuỳ chỉnh trong các trường hợp này, bạn có các lựa chọn sau:
- Đặt lại rõ ràng các thuộc tính tuỳ chỉnh trong chính sách mã thông báo làm mới và đặt giá trị hiển thị của các thuộc tính đó thành false. Trong trường hợp này, bạn có thể cần truy xuất các giá trị tuỳ chỉnh ban đầu từ mã truy cập gốc bằng cách sử dụng chính sách Get OAuthV2Info.
- Sử dụng chính sách xử lý hậu kỳ JavaScript để trích xuất mọi thuộc tính tuỳ chỉnh mà bạn không muốn thấy trong phản hồi theo cách thủ công.
Hãy xem thêm bài viết Tuỳ chỉnh mã thông báo và Mã uỷ quyền.
Mặc định: |
|
Sự hiện diện: |
Không bắt buộc |
Giá trị hợp lệ: |
|
Được dùng với các loại quyền: |
|
Phần tử <ClientId>
<ClientId>request.formparam.client_id</ClientId>
Trong một số trường hợp, ứng dụng khách phải gửi mã ứng dụng khách đến máy chủ uỷ quyền. Phần tử này cho phép bạn chỉ định vị trí mà Edge nên tìm mã ứng dụng khách. Vị trí hợp lệ duy nhất mà bạn có thể đặt là vị trí mặc định, biến luồng request.formparam.client_id
. Không hỗ trợ đặt ClientId
thành bất kỳ biến nào khác.
Xem thêm bài viết Yêu cầu mã truy cập và mã uỷ quyền.
Mặc định: |
request.formparam.client_id (một x-www-form-url encrypted và được chỉ định trong nội dung của yêu cầu) |
Sự hiện diện: |
Không bắt buộc |
Loại: | Chuỗi |
Giá trị hợp lệ: | Biến luồng: request.formparam.client_id |
Được dùng với các loại quyền: |
Cũng có thể được sử dụng với thao tác GeneratevalidateCode. |
Phần tử <Code>
<Code>request.queryparam.code</Code>
Trong quy trình loại cấp quyền uỷ quyền, ứng dụng phải gửi mã uỷ quyền đến máy chủ uỷ quyền (Apigee Edge). Phần tử này cho phép bạn chỉ định nơi Edge nên tìm mã uỷ quyền. Ví dụ: sự kiện này có thể được gửi dưới dạng tham số truy vấn, tiêu đề HTTP hoặc tham số biểu mẫu (mặc định).
Biến request.queryparam.auth_code
cho biết rằng mã uỷ quyền phải hiển thị dưới dạng tham số truy vấn, chẳng hạn như ?auth_code=AfGlvs9
. Ví dụ: để yêu cầu mã uỷ quyền trong tiêu đề HTTP, hãy đặt giá trị này thành request.header.auth_code
. Xem thêm phần Yêu cầu mã truy cập và mã uỷ quyền.
Mặc định: |
request.formparam.code (một x-www-form-url encrypted và được chỉ định trong nội dung yêu cầu) |
Sự hiện diện: |
không bắt buộc |
Loại: | Chuỗi |
Giá trị hợp lệ: | Mọi biến luồng có thể truy cập vào chính sách trong thời gian chạy |
Được dùng với các loại quyền: | authorization_code |
Phần tử<Hết hạn>
<ExpiresIn>10000</ExpiresIn>
Thực thi thời gian hết hạn của mã thông báo truy cập và mã uỷ quyền tính bằng mili giây. (Đối với mã làm mới, hãy sử dụng <RefreshTokenExpiresIn>
.) Giá trị thời gian hết hạn là giá trị do hệ thống tạo cộng với giá trị <ExpiresIn>
. Nếu bạn đặt <ExpiresIn>
thành -1, thì mã thông báo hoặc mã sẽ hết hạn theo thời hạn mã truy cập OAuth tối đa.
Nếu bạn không chỉ định <ExpiresIn>
, hệ thống sẽ áp dụng một giá trị mặc định được định cấu hình ở cấp hệ thống.
Bạn cũng có thể đặt thời gian hết hạn trong thời gian chạy bằng cách sử dụng giá trị mặc định được mã hoá cứng hoặc tham chiếu đến một biến luồng. Ví dụ: bạn có thể lưu trữ giá trị thời hạn của mã thông báo trong bản đồ ánh xạ giá trị khoá, truy xuất, chỉ định giá trị đó cho một biến và tham chiếu giá trị đó trong chính sách. Ví dụ: kvm.oauth.expires_in
Với Apigee Edge cho Cloud công cộng, Edge sẽ lưu giữ các thực thể sau trong bộ nhớ đệm trong tối thiểu 180 giây sau khi các thực thể được truy cập.
- Mã truy cập OAuth. Điều này có nghĩa là mã thông báo bị thu hồi vẫn có thể thành công trong tối đa 3 phút cho đến khi giới hạn bộ nhớ đệm của mã hết hạn.
- Thực thể Dịch vụ quản lý khoá (KMS) (Ứng dụng, Nhà phát triển, Sản phẩm API).
- Thuộc tính tuỳ chỉnh trên mã thông báo OAuth và thực thể KMS.
khổ thơ sau đây chỉ rõ một biến luồng và một giá trị mặc định. Lưu ý rằng giá trị biến luồng được ưu tiên hơn giá trị mặc định được chỉ định.
<ExpiresIn ref="kvm.oauth.expires_in"> 3600000 <!--default value in milliseconds--> </ExpiresIn>
Edge không hỗ trợ cách buộc hết hạn mã thông báo sau khi mã đó được tạo. Nếu bạn cần buộc mã thông báo hết hạn (ví dụ: dựa trên một điều kiện), thì giải pháp khả thi được mô tả trong bài đăng này trên Cộng đồng Apigee.
Theo mặc định, các mã truy cập đã hết hạn sẽ tự động bị xoá hoàn toàn khỏi hệ thống Apigee Edge sau 3 ngày kể từ khi hết hạn. Xem thêm bài viết Đẩy mạnh mã thông báo truy cập
Đám mây riêng tư: Đối với quá trình cài đặt Edge dành cho đám mây riêng tư, giá trị mặc định được đặt bởi thuộc tính conf_keymanagement_oauth_auth_code_expiry_time_in_millis
.
Cách đặt thuộc tính này:
- Mở tệp
message-processor.properties
trong trình chỉnh sửa. Nếu tệp không tồn tại, hãy tạo tệp:vi /opt/apigee/customer/application/message-processor.properties
- Thiết lập tài sản như mong muốn:
conf_keymanagement_oauth_auth_code_expiry_time_in_millis=3600000
- Đảm bảo tệp thuộc tính thuộc sở hữu của người dùng "apigee":
chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
- Khởi động lại Bộ xử lý thư.
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
Mặc định: |
Nếu không được chỉ định, hệ thống sẽ áp dụng một giá trị mặc định được định cấu hình ở cấp hệ thống. |
Sự hiện diện: |
Không bắt buộc |
Loại: | Số nguyên |
Giá trị hợp lệ: |
|
Được dùng với các loại quyền: |
Cũng được sử dụng với hoạt động GenerateCommitCode. |
Phần tử <ExternalAccessToken>
<ExternalAccessToken>request.queryparam.external_access_token</ExternalAccessToken>
Cho Apigee Edge biết nơi cần tìm mã truy cập bên ngoài (mã truy cập không do Apigee Edge tạo ra).
Biến request.queryparam.external_access_token
cho biết rằng mã truy cập bên ngoài phải hiển thị dưới dạng tham số truy vấn, chẳng hạn như ?external_access_token=12345678
. Ví dụ: để yêu cầu mã truy cập bên ngoài trong tiêu đề HTTP, hãy đặt giá trị này thành request.header.external_access_token
. Hãy xem thêm bài viết Sử dụng mã thông báo OAuth của bên thứ ba.
Phần tử <ExternalUỷ quyền>
<ExternalAuthorization>true</ExternalAuthorization>
Nếu phần tử này sai hoặc không hiện diện, thì Edge sẽ xác thực client_id và client_secret thông thường dựa trên cửa hàng uỷ quyền Apigee Edge. Hãy sử dụng phần tử này khi bạn muốn làm việc với mã thông báo OAuth của bên thứ ba. Để biết thông tin chi tiết về cách sử dụng phần tử này, hãy xem phần Sử dụng mã thông báo OAuth của bên thứ ba.
Mặc định: |
false |
Sự hiện diện: |
Không bắt buộc |
Loại: | Boolean |
Giá trị hợp lệ: | true hoặc false |
Được dùng với các loại quyền: |
|
Phần tử <ExternalCấpCode>
<ExternalAuthorizationCode>request.queryparam.external_auth_code</ExternalAuthorizationCode>
Cho Apigee Edge biết nơi cần tìm mã xác thực bên ngoài (mã xác thực không do Apigee Edge tạo).
Biến request.queryparam.external_auth_code
cho biết rằng mã xác thực bên ngoài phải hiển thị dưới dạng tham số truy vấn, chẳng hạn như ?external_auth_code=12345678
. Ví dụ: để yêu cầu mã xác thực bên ngoài trong tiêu đề HTTP, hãy đặt giá trị này thành request.header.external_auth_code
. Hãy xem thêm bài viết Sử dụng mã thông báo OAuth của bên thứ ba.
Phần tử <ExternalRefreshToken>
<ExternalRefreshToken>request.queryparam.external_refresh_token</ExternalRefreshToken>
Cho Apigee Edge biết nơi cần tìm mã làm mới bên ngoài (mã làm mới không do Apigee Edge tạo).
Biến request.queryparam.external_refresh_token
cho biết rằng mã làm mới bên ngoài phải hiển thị dưới dạng tham số truy vấn, chẳng hạn như ?external_refresh_token=12345678
. Ví dụ: để yêu cầu mã làm mới bên ngoài trong tiêu đề HTTP, hãy đặt giá trị này thành request.header.external_refresh_token
. Hãy xem thêm bài viết Sử dụng mã thông báo OAuth của bên thứ ba.
Phần tử <GenerateResponse>
<GenerateResponse enabled='true'/>
Nếu bạn đặt thành true
, chính sách sẽ tạo và trả về một phản hồi. Ví dụ: đối với GenerateAccessToken, phản hồi có thể có dạng như sau:
{ "issued_at" : "1467841035013", "scope" : "read", "application_name" : "e31b8d06-d538-4f6b-9fe3-8796c11dc930", "refresh_token_issued_at" : "1467841035013", "status" : "approved", "refresh_token_status" : "approved", "api_product_list" : "[Product1, nhl_product]", "expires_in" : "1799", "developer.email" : "edward@slalom.org", "token_type" : "BearerToken", "refresh_token" : "rVSmm3QaNa0xBVFbUISz1NZI15akvgLJ", "client_id" : "Adfsdvoc7KX5Gezz9le745UEql5dDmj", "access_token" : "AnoHsh2oZ6EFWF4h0KrA0gC5og3a", "organization_name" : "cerruti", "refresh_token_expires_in" : "0", "refresh_count" : "0" }
Nếu false
thì không có phản hồi nào được gửi. Thay vào đó, một tập hợp các biến luồng sẽ được điền sẵn bằng các giá trị liên quan đến hàm của chính sách. Ví dụ: một biến luồng có tên là oauthv2authcode.OAuthV2-GenerateAuthorizationCode.code
sẽ được điền bằng mã xác thực mới đúc. Xin lưu ý rằng expires_in được biểu thị bằng giây trong phản hồi.
Mặc định: |
false |
Sự hiện diện: |
Không bắt buộc |
Loại: | string |
Giá trị hợp lệ: | true hoặc false |
Được dùng với các loại quyền: |
|
Phần tử <GenerateErrorResponse>
<GenerateErrorResponse enabled='true'/>
Nếu bạn đặt thành true
, chính sách này sẽ tạo và trả về một phản hồi nếu thuộc tính ContinueOnError được đặt thành true. Nếu false
(mặc định) thì sẽ không có phản hồi nào được gửi. Thay vào đó, một tập hợp các biến luồng được điền sẵn bằng các giá trị liên quan đến
hàm của chính sách.
Mặc định: |
false |
Sự hiện diện: |
Không bắt buộc |
Loại: | string |
Giá trị hợp lệ: | true hoặc false |
Được dùng với các loại quyền: |
|
<GrantType>
<GrantType>request.queryparam.grant_type</GrantType>
Cho chính sách biết nơi tìm thông số loại tài trợ được chuyển trong một yêu cầu. Theo quy cách của OAuth 2.0, loại cấp quyền phải được cung cấp cùng với các yêu cầu mã truy cập và mã uỷ quyền. Biến này có thể là tiêu đề, tham số truy vấn hoặc tham số biểu mẫu (mặc định).
Ví dụ: request.queryparam.grant_type
cho biết rằng Mật khẩu phải hiển thị dưới dạng tham số truy vấn, chẳng hạn như ?grant_type=password
.
Để yêu cầu loại quyền cấp trong tiêu đề HTTP, chẳng hạn, hãy đặt giá trị này thành request.header.grant_type
. Xem thêm bài viết Yêu cầu mã truy cập và mã uỷ quyền.
Mặc định: |
request.formparam.grant_type (một x-www-form-url encrypted và được chỉ định trong nội dung yêu cầu) |
Sự hiện diện: |
Không bắt buộc |
Loại: | string |
Giá trị hợp lệ: | Một biến, như đã giải thích ở trên. |
Được dùng với các loại quyền: |
|
Phần tử <Operation>
<Operation>GenerateAuthorizationCode</Operation>
Thao tác OAuth 2.0 do chính sách thực thi.
Mặc định: |
Nếu bạn không chỉ định |
Sự hiện diện: |
Không bắt buộc |
Loại: | Chuỗi |
Giá trị hợp lệ: |
|
Phần tử <PassWord>
<PassWord>request.queryparam.password</PassWord>
Phần tử này được sử dụng với kiểu cấp mật khẩu. Với kiểu cấp mật khẩu, bạn phải cung cấp thông tin đăng nhập của người dùng (mật khẩu và tên người dùng) cho chính sách OAuthV2. Các phần tử <PassWord>
và <UserName>
được dùng để chỉ định các biến mà Edge có thể tìm thấy các giá trị này. Nếu các phần tử này không được chỉ định, thì chính sách sẽ tìm các giá trị (theo mặc định) trong các tham số biểu mẫu có tên là username
và password
. Nếu không tìm thấy các giá trị này, chính sách sẽ gửi ra lỗi. Bạn có thể sử dụng các phần tử <PassWord>
và <UserName>
để tham chiếu bất kỳ biến luồng nào chứa thông tin xác thực.
Ví dụ: bạn có thể chuyển mật khẩu vào yêu cầu mã thông báo bằng cách sử dụng tham số truy vấn và thiết lập phần tử như sau: <PassWord>request.queryparam.password</PassWord>
.
Để yêu cầu mật khẩu trong tiêu đề HTTP, hãy đặt giá trị này thành request.header.password
.
Chính sách OAuthV2 không làm gì thêm đối với các giá trị thông tin đăng nhập này; Edge chỉ đơn giản là xác minh rằng các giá trị đó còn tồn tại. Nhà phát triển API có quyền tuỳ ý truy xuất yêu cầu giá trị và gửi cho nhà cung cấp danh tính trước khi chính sách tạo mã thông báo thực thi.
Xem thêm bài viết Yêu cầu mã truy cập và mã uỷ quyền.
Mặc định: |
request.formparam.password (một x-www-form-urlcoded và được chỉ định trong nội dung yêu cầu) |
Sự hiện diện: |
Không bắt buộc |
Loại: | Chuỗi |
Giá trị hợp lệ: | Mọi biến luồng có sẵn cho chính sách trong thời gian chạy. |
Được dùng với các loại quyền: | mật khẩu |
Phần tử <RedirectUri>
<RedirectUri>request.queryparam.redirect_uri</RedirectUri>
Chỉ định nơi mà Edge nên tìm kiếm tham số redirect_uri
trong yêu cầu.
Giới thiệu về URI chuyển hướng
URI chuyển hướng được dùng với mã uỷ quyền và các kiểu cấp quyền ngầm ẩn. URI chuyển hướng thông báo cho máy chủ uỷ quyền (Edge) biết nơi gửi mã uỷ quyền (đối với loại cấp mã xác thực) hoặc mã truy cập (đối với loại cấp quyền ngầm ẩn). Bạn cần hiểu rõ khi nào tham số này là bắt buộc, khi nào là không bắt buộc và cách sử dụng tham số này:
-
(bắt buộc) Nếu URL gọi lại được đăng ký với ứng dụng của nhà phát triển liên kết với khoá ứng dụng khách của yêu cầu và
redirect_uri
có trong yêu cầu, thì 2 URL này phải khớp chính xác. Nếu không khớp, hàm sẽ trả về lỗi. Để biết thông tin về cách đăng ký ứng dụng dành cho nhà phát triển trên Edge và cách chỉ định URL gọi lại, hãy xem phần Đăng ký ứng dụng và quản lý khoá API. - (không bắt buộc) Nếu một URL gọi lại được đăng ký và
redirect_uri
bị thiếu trong yêu cầu, thì Edge sẽ chuyển hướng đến URL gọi lại đã đăng ký. - (bắt buộc) Nếu chưa đăng ký URL gọi lại, thì bạn bắt buộc phải cung cấp
redirect_uri
. Xin lưu ý rằng trong trường hợp này, Edge sẽ chấp nhận BẤT KỲ URL nào. Trường hợp này có thể gây ra vấn đề bảo mật nên bạn chỉ nên sử dụng ứng dụng này với các ứng dụng đáng tin cậy. Nếu ứng dụng khách không đáng tin cậy, thì phương pháp hay nhất là luôn yêu cầu đăng ký URL gọi lại.
Bạn có thể gửi tham số này trong tham số truy vấn hoặc trong tiêu đề. Biến request.queryparam.redirect_uri
cho biết rằng RedirectUri phải hiển thị dưới dạng tham số truy vấn, chẳng hạn như ?redirect_uri=login.myapp.com
. Ví dụ: để yêu cầu RedirectUri trong tiêu đề HTTP, đặt giá trị này thành request.header.redirect_uri
. Hãy xem thêm phần Yêu cầu mã truy cập và mã uỷ quyền.
Mặc định: |
request.formparam.redirect_uri (một x-www-form-urlđược mã hoá và được chỉ định trong nội dung yêu cầu) |
Sự hiện diện: |
Không bắt buộc |
Loại: | Chuỗi |
Giá trị hợp lệ: | Mọi biến luồng có thể truy cập được trong chính sách trong thời gian chạy |
Được dùng với các loại quyền: |
Cũng được sử dụng với thao tác GenerateCredentialCode. |
Phần tử <RefreshToken>
<RefreshToken>request.queryparam.refreshtoken</RefreshToken>
Khi yêu cầu mã truy cập bằng mã làm mới, bạn phải cung cấp mã làm mới trong yêu cầu. Phần tử này cho phép bạn chỉ định nơi Edge nên tìm mã làm mới. Ví dụ: URL này có thể được gửi dưới dạng tham số truy vấn, tiêu đề HTTP hoặc tham số biểu mẫu (mặc định).
Biến request.queryparam.refreshtoken
cho biết rằng mã làm mới phải hiển thị dưới dạng tham số truy vấn, chẳng hạn như ?refresh_token=login.myapp.com
. Chẳng hạn, để yêu cầu RefreshToken trong tiêu đề HTTP, hãy đặt giá trị này thành request.header.refresh_token
. Hãy xem thêm phần Yêu cầu mã truy cập và mã uỷ quyền.
Mặc định: |
request.formparam.refresh_token (một x-www-form-url encrypted và được chỉ định trong nội dung yêu cầu) |
Sự hiện diện: |
Không bắt buộc |
Loại: | Chuỗi |
Giá trị hợp lệ: | Mọi biến luồng có thể truy cập được trong chính sách trong thời gian chạy |
Được dùng với các loại quyền: |
|
Phần tử <RefreshToken vàiIn>
<RefreshTokenExpiresIn>1000</RefreshTokenExpiresIn>
Thực thi thời gian hết hạn của mã thông báo làm mới tính bằng mili giây. Giá trị thời gian hết hạn là một giá trị do hệ thống tạo cộng với giá trị <RefreshTokenExpiresIn>
. Nếu bạn đặt <RefreshTokenExpiresIn>
thành -1, thì mã làm mới sẽ hết hạn theo thời hạn mã làm mới OAuth tối đa. Nếu bạn không chỉ định <RefreshTokenExpiresIn>
, thì theo mặc định, thời hạn là vô thời hạn.
Bạn cũng có thể đặt thời gian hết hạn trong thời gian chạy bằng cách sử dụng giá trị mặc định được mã hoá cứng hoặc tham chiếu đến một biến luồng. Ví dụ: bạn có thể lưu trữ giá trị thời hạn của mã thông báo trong bản đồ ánh xạ giá trị khoá, truy xuất, chỉ định giá trị đó cho một biến và tham chiếu giá trị đó trong chính sách. Ví dụ: kvm.oauth.expires_in
.
khổ thơ sau đây chỉ rõ một biến luồng và một giá trị mặc định. Lưu ý rằng giá trị biến flow được ưu tiên hơn giá trị mặc định được chỉ định.
<RefreshTokenExpiresIn ref="kvm.oauth.expires_in"> 3600000 <!--default value in milliseconds--> </RefreshTokenExpiresIn>
Đám mây riêng tư: Đối với quá trình cài đặt Edge dành cho đám mây riêng tư, giá trị mặc định được đặt bởi thuộc tính conf_keymanagement_oauth_refresh_token_expiry_time_in_millis
.
Cách đặt thuộc tính này:
- Mở tệp
message-processor.properties
trong trình chỉnh sửa. Nếu tệp không tồn tại, hãy tạo tệp:vi /opt/apigee/customer/application/message-processor.properties
- Thiết lập tài sản như mong muốn:
conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000
- Đảm bảo tệp thuộc tính thuộc sở hữu của người dùng "apigee":
chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
- Khởi động lại Bộ xử lý thư.
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
Mặc định: |
Nếu không được chỉ định, hệ thống sẽ áp dụng một giá trị mặc định được định cấu hình ở cấp hệ thống. |
Sự hiện diện: |
Không bắt buộc |
Loại: | Số nguyên |
Giá trị hợp lệ: |
|
Được dùng với các loại quyền: |
|
"refresh_token_expires_in" : "0"
.Phần tử <ResponseType>
<ResponseType>request.queryparam.response_type</ResponseType>
Phần tử này thông báo cho Edge về loại quyền mà ứng dụng khách đang yêu cầu. Phương thức này chỉ được dùng với mã uỷ quyền và luồng kiểu cấp quyền ngầm ẩn.
Theo mặc định, Edge sẽ tìm kiếm giá trị loại phản hồi trong tham số truy vấn response_type
. Nếu bạn muốn ghi đè hành vi mặc định này, hãy sử dụng phần tử <ResponseType> để định cấu hình một biến luồng chứa giá trị loại phản hồi. Ví dụ: nếu bạn đặt phần tử này thành request.header.response_type
, Edge sẽ tìm loại phản hồi sẽ được truyền trong tiêu đề yêu cầu. Xem thêm bài viết Yêu cầu mã truy cập và mã uỷ quyền.
Mặc định: |
request.formparam.Response_type (một x-www-form-urlcoded và được chỉ định trong nội dung yêu cầu) |
Sự hiện diện: |
Không bắt buộc. Sử dụng phần tử này nếu bạn muốn ghi đè hành vi mặc định. |
Loại: | Chuỗi |
Giá trị hợp lệ: | code (đối với loại cấp mã uỷ quyền) hoặc token (đối với loại cấp ngầm ẩn) |
Được dùng với các loại quyền: |
|
Phần tử <UsageRefreshToken>
<ReuseRefreshToken>true</ReuseRefreshToken>
Khi bạn đặt thành true
, mã làm mới hiện có sẽ được sử dụng lại cho đến khi hết hạn. Nếu là false
, thì mã làm mới sẽ do Apigee Edge phát hành khi trình bày mã làm mới hợp lệ.
Mặc định: |
|
Sự hiện diện: |
không bắt buộc |
Loại: | boolean |
Giá trị hợp lệ: |
|
Được dùng với loại cấp quyền: |
|
Phần tử <Scope>
<Scope>request.queryparam.scope</Scope>
Nếu phần tử này có mặt trong một trong các chính sách GenerateAccessToken hoặc GenerateCommitCode, thì phần tử này sẽ được dùng để chỉ định phạm vi nào cấp mã thông báo hoặc mã. Các giá trị này thường được chuyển đến chính sách trong yêu cầu từ ứng dụng khách. Bạn có thể định cấu hình phần tử để lấy biến luồng, cho phép bạn lựa chọn cách truyền phạm vi trong một yêu cầu. Trong ví dụ sau, request.queryparam.scope
cho biết rằng phạm vi phải xuất hiện dưới dạng tham số truy vấn, chẳng hạn như ?scope=READ
. Chẳng hạn, để yêu cầu phạm vi trong tiêu đề HTTP, hãy đặt giá trị này thành request.header.scope
.
Nếu phần tử này xuất hiện trong một chính sách "VerifyAccessToken", thì phần tử này sẽ được dùng để chỉ định phạm vi mà chính sách sẽ thực thi. Trong loại chính sách này, giá trị phải là tên phạm vi "được mã hoá cứng" – bạn không thể sử dụng biến. Ví dụ:
<Scope>A B</Scope>
Xem thêm bài viết Xử lý phạm vi OAuth2 và Yêu cầu mã truy cập và mã uỷ quyền.
Mặc định: |
Không có phạm vi |
Sự hiện diện: |
Không bắt buộc |
Loại: | Chuỗi |
Giá trị hợp lệ: |
Nếu được dùng cùng với chính sách Tạo*, thì biến luồng sẽ là một biến. Nếu được dùng với VerifyAccessToken, một danh sách tên phạm vi (chuỗi) được phân tách bằng dấu cách. |
Được dùng với các loại quyền: |
|
Phần tử <State>
<State>request.queryparam.state</State>
Trong trường hợp ứng dụng khách phải gửi thông tin trạng thái đến máy chủ uỷ quyền, phần tử này sẽ cho phép bạn chỉ định nơi Edge tìm giá trị trạng thái. Ví dụ: sự kiện này có thể được gửi dưới dạng tham số truy vấn hoặc tiêu đề HTTP. Giá trị trạng thái thường được dùng làm biện pháp bảo mật để ngăn chặn các cuộc tấn công CSRF.
Ví dụ: request.queryparam.state
cho biết rằng trạng thái phải hiện diện dưới dạng tham số truy vấn, chẳng hạn như ?state=HjoiuKJH32
. Ví dụ: để yêu cầu trạng thái trong tiêu đề HTTP, hãy đặt giá trị này thành request.header.state
. Hãy xem thêm bài viết Yêu cầu mã truy cập và mã uỷ quyền.
Mặc định: |
Không có tiểu bang nào |
Sự hiện diện: |
Không bắt buộc |
Loại: | Chuỗi |
Giá trị hợp lệ: | Mọi biến luồng có thể truy cập vào chính sách trong thời gian chạy |
Được dùng với các loại quyền: |
|
Phần tử <StoreToken>
<StoreToken>true</StoreToken>
Đặt phần tử này thành true
khi phần tử <ExternalAuthorization>
là true
. Phần tử <StoreToken>
yêu cầu Apigee Edge lưu trữ mã truy cập bên ngoài. Nếu không, yêu cầu này sẽ không được duy trì.
Mặc định: |
false |
Sự hiện diện: |
Không bắt buộc |
Loại: | Boolean |
Giá trị hợp lệ: | true hoặc false |
Được dùng với các loại quyền: |
|
Phần tử <SupportedGrantTypes>/<GrantType>
<SupportedGrantTypes> <GrantType>authorization_code</GrantType> <GrantType>client_credentials</GrantType> <GrantType>implicit</GrantType> <GrantType>password</GrantType> </SupportedGrantTypes>
Chỉ định các loại cấp quyền được hỗ trợ bởi một điểm cuối của mã thông báo OAuth trên Apigee Edge. Một điểm cuối có thể hỗ trợ nhiều loại cấp quyền (nghĩa là một điểm cuối có thể được định cấu hình để phân phối mã truy cập cho nhiều loại cấp quyền). Để biết thêm thông tin về điểm cuối, hãy xem bài viết Tìm hiểu về điểm cuối của OAuth. Loại cấp quyền được truyền vào yêu cầu mã thông báo trong tham số grant_type
.
Nếu bạn không chỉ định loại cấp quyền được hỗ trợ, thì loại cấp duy nhất được phép là authorization_code
và implicit
. Hãy xem thêm phần tử <GrantType> (là phần tử cấp cao hơn dùng để chỉ định trong đó Apigee Edge nên tìm kiếm tham số grant_type
được truyền trong yêu cầu của ứng dụng khách). Edge sẽ đảm bảo rằng giá trị của tham số grant_type
khớp với một trong các loại quyền được hỗ trợ).
Mặc định: |
mã_uỷ quyền và ngầm định |
Sự hiện diện: |
Bắt buộc |
Loại: | Chuỗi |
Giá trị hợp lệ: |
|
Phần tử <Tokens>/<Token>
Được dùng với các hoạt động ValidationToken và InvalidateToken. Hãy xem thêm phần Phê duyệt và thu hồi mã truy cập. Phần tử <Token> xác định biến luồng xác định nguồn của mã thông báo cần bị thu hồi. Nếu dự kiến nhà phát triển sẽ gửi mã truy cập dưới dạng tham số truy vấn có tên access_token
, chẳng hạn, hãy sử dụng request.queryparam.access_token
.
Phần tử <UserName>
<UserName>request.queryparam.user_name</UserName>
Phần tử này được sử dụng với kiểu cấp mật khẩu. Với kiểu cấp mật khẩu, bạn phải cung cấp thông tin đăng nhập của người dùng (mật khẩu và tên người dùng) cho chính sách OAuthV2. Các phần tử <PassWord>
và <UserName>
được dùng để chỉ định các biến mà Edge có thể tìm thấy các giá trị này. Nếu các phần tử này không được chỉ định, thì chính sách sẽ tìm các giá trị (theo mặc định) trong các tham số biểu mẫu có tên là username
và password
. Nếu không tìm thấy các giá trị này, chính sách sẽ gửi ra lỗi. Bạn có thể sử dụng các phần tử <PassWord>
và <UserName>
để tham chiếu bất kỳ biến luồng nào chứa thông tin xác thực.
Ví dụ: bạn có thể truyền tên người dùng vào một tham số truy vấn và thiết lập phần tử <UserName>
như sau: <UserName>request.queryparam.username</UserName>
.
Để yêu cầu tên người dùng trong tiêu đề HTTP, hãy đặt giá trị này thành request.header.username
.
Chính sách OAuthV2 không làm gì thêm đối với các giá trị thông tin đăng nhập này; Edge chỉ đơn giản là xác minh rằng các giá trị đó còn tồn tại. Nhà phát triển API có quyền tuỳ ý truy xuất yêu cầu giá trị và gửi cho nhà cung cấp danh tính trước khi chính sách tạo mã thông báo thực thi.
Xem thêm bài viết Yêu cầu mã truy cập và mã uỷ quyền.
Mặc định: |
request.formparam.username (a x-www-form-url encrypted và được chỉ định trong nội dung yêu cầu) |
Sự hiện diện: |
Không bắt buộc |
Loại: | Chuỗi |
Giá trị hợp lệ: | Chế độ cài đặt biến bất kỳ. |
Được dùng với các loại quyền: | mật khẩu |
Xác minh mã truy cập
Sau khi thiết lập điểm cuối của mã thông báo cho một proxy API, một chính sách OAuthV2 tương ứng chỉ định thao tác VerifyAccessToken
sẽ được đính kèm vào Luồng (Flow) hiển thị tài nguyên được bảo vệ.
Ví dụ: để đảm bảo rằng tất cả yêu cầu gửi đến một API đều được uỷ quyền, chính sách sau đây sẽ thực thi quy trình xác minh mã truy cập:
<OAuthV2 name="VerifyOAuthAccessToken"> <Operation>VerifyAccessToken</Operation> </OAuthV2>
Chính sách này được đính kèm vào tài nguyên API cần được bảo vệ. Để đảm bảo rằng tất cả yêu cầu gửi đến một API đều được xác minh, hãy đính kèm chính sách này vào PreFlow của yêu cầu ProxyEndpoint như sau:
<PreFlow> <Request> <Step><Name>VerifyOAuthAccessToken</Name></Step> </Request> </PreFlow>
Bạn có thể dùng các phần tử không bắt buộc sau đây để ghi đè chế độ cài đặt mặc định cho thao tác VerifyAccessToken.
Tên | Nội dung mô tả |
---|---|
Phạm vi |
Danh sách các phạm vi được phân tách bằng dấu cách. Quy trình xác minh sẽ thành công nếu mã truy cập có ít nhất một trong các phạm vi đã nêu. Ví dụ: chính sách sau đây sẽ kiểm tra mã truy cập để đảm bảo mã đó chứa ít nhất một trong các phạm vi được liệt kê. Nếu đã có quyền READ hoặc WRITE, quá trình xác minh sẽ thành công. <OAuthV2 name="ValidateOauthScopePolicy"> <Operation>VerifyAccessToken</Operation> <Scope>READ WRITE</Scope> </OAuthV2> |
AccessToken | Biến nơi đặt mã truy cập dự kiến. Ví dụ: request.queryparam.accesstoken Theo mặc định, ứng dụng dự kiến sẽ hiển thị mã truy cập trong tiêu đề HTTP cấp quyền, theo thông số kỹ thuật của OAuth 2.0. Hãy sử dụng chế độ cài đặt này nếu mã truy cập dự kiến sẽ xuất hiện ở một vị trí không chuẩn, chẳng hạn như tham số truy vấn hoặc tiêu đề HTTP có tên không phải là Uỷ quyền. |
Hãy xem thêm bài viết Xác minh mã truy cập và Yêu cầu mã truy cập và mã uỷ quyền.
Chỉ định vị trí cho biến yêu cầu
Đối với mỗi loại cấp quyền, chính sách này sẽ đưa ra giả định về vị trí hoặc thông tin bắt buộc trong thông báo yêu cầu. Các giả định này dựa trên thông số kỹ thuật của OAuth 2.0. Nếu ứng dụng của bạn cần không nhất quán với thông số kỹ thuật của OAuth 2.0, thì bạn có thể chỉ định vị trí dự kiến cho mỗi tham số. Ví dụ: khi xử lý mã uỷ quyền, bạn có thể chỉ định vị trí của mã uỷ quyền, mã ứng dụng khách, URI chuyển hướng và phạm vi. Các đối số này có thể được chỉ định dưới dạng tiêu đề HTTP, tham số truy vấn hoặc tham số biểu mẫu.
Ví dụ bên dưới minh hoạ cách bạn có thể chỉ định vị trí của các tham số mã uỷ quyền bắt buộc làm tiêu đề HTTP:
... <GrantType>request.header.grant_type</GrantType> <Code>request.header.code</Code> <ClientId>request.header.client_id</ClientId> <RedirectUri>request.header.redirect_uri</RedirectUri> <Scope>request.header.scope</Scope> ...
Hoặc, nếu cần để hỗ trợ cơ sở ứng dụng khách, bạn có thể kết hợp và so khớp tiêu đề cũng như tham số truy vấn:
... <GrantType>request.header.grant_type</GrantType> <Code>request.header.code</Code> <ClientId>request.queryparam.client_id</ClientId> <RedirectUri>request.queryparam.redirect_uri</RedirectUri> <Scope>request.queryparam.scope</Scope> ...
Bạn chỉ có thể định cấu hình một vị trí cho mỗi thông số.
Biến luồng
Các biến luồng xác định trong bảng này được điền sẵn khi các chính sách OAuth tương ứng được thực thi. Do đó, các chính sách hoặc ứng dụng khác thực thi trong luồng proxy API có thể được dùng.
Thao tác VerifyAccessToken
Sẽ thực thi thao tác VerifyAccessToken, một số lượng lớn các biến luồng sẽ được điền sẵn trong ngữ cảnh thực thi của proxy. Các biến này cung cấp cho bạn các thuộc tính liên quan đến mã truy cập, ứng dụng của nhà phát triển, nhà phát triển và công ty. Ví dụ: bạn có thể sử dụng chính sách khối composeMessage hoặc JavaScript để đọc bất kỳ biến nào trong số các biến này và sử dụng chúng nếu cần trong tương lai. Các biến này cũng có thể hữu ích cho mục đích gỡ lỗi.
proxy.pathsuffix
). Bạn không bắt buộc phải thiết lập rõ ràng biến flow.resource.name.
Trong trường hợp các sản phẩm API không được định cấu hình bằng môi trường và proxy API hợp lệ, thì bạn phải thiết lập flow.resource.name
một cách rõ ràng để điền các biến sản phẩm API trong luồng. Để biết thông tin chi tiết về cấu hình sản phẩm, hãy xem phần Sử dụng API Quản lý Edge để phát hành API.
Biến dành riêng cho mã thông báo
Biến | Nội dung mô tả |
---|---|
organization_name |
Tên của tổ chức nơi proxy đang thực thi. |
developer.id |
Mã của nhà phát triển liên kết với ứng dụng khách đã đăng ký. |
developer.app.name |
Tên của nhà phát triển liên kết với ứng dụng khách đã đăng ký. |
client_id |
Mã ứng dụng khách của ứng dụng đã đăng ký. |
grant_type |
Loại quyền cấp được liên kết với yêu cầu. |
token_type |
Loại mã thông báo được liên kết với yêu cầu. |
access_token |
Mã truy cập đang được xác minh. |
accesstoken.{custom_attribute} |
Thuộc tính tuỳ chỉnh có tên trong mã truy cập. |
issued_at |
Ngày cấp mã truy cập được biểu thị bằng thời gian bắt đầu của hệ thống Unix, tính bằng mili giây. |
expires_in |
Thời gian hết hạn của mã truy cập. Được biểu thị trong
giây. Mặc dù phần tử ExpiresIn đặt thời hạn tính bằng mili giây, nhưng đối với các biến luồng và phản hồi của mã thông báo, giá trị này được biểu thị theo giây. |
status |
Trạng thái của mã truy cập (ví dụ: đã phê duyệt hoặc bị thu hồi). |
scope |
Phạm vi (nếu có) được liên kết với mã truy cập. |
apiproduct.<custom_attribute_name> |
Thuộc tính tuỳ chỉnh đã đặt tên của sản phẩm API liên kết với ứng dụng khách đã đăng ký. |
apiproduct.name |
Tên của sản phẩm API liên kết với ứng dụng khách đã đăng ký. |
revoke_reason |
(Chỉ dành cho kết hợp API) Cho biết lý do mã truy cập bị thu hồi. Giá trị có thể là |
Biến dành riêng cho ứng dụng
Các biến này liên quan đến Ứng dụng của nhà phát triển liên kết với mã thông báo đó.
Biến | Nội dung mô tả |
---|---|
app.name |
|
app.id |
|
app.accessType |
|
app.callbackUrl |
|
app.status |
được phê duyệt hoặc thu hồi |
app.scopes |
|
app.appFamily |
|
app.apiproducts |
|
app.appParentStatus |
|
app.appType |
Ví dụ: Nhà phát triển |
app.appParentId |
|
app.created_by |
|
app.created_at |
|
app.last_modified_at |
|
app.last_modified_by |
|
app.{custom_attributes} |
Thuộc tính tuỳ chỉnh đã đặt tên của ứng dụng khách đã đăng ký. |
Biến dành riêng cho nhà phát triển
Nếu app.appType là "Company", thì thuộc tính của công ty sẽ được điền và nếu app.appType là "Nhà phát triển", thì thuộc tính của nhà phát triển sẽ được điền.
Biến | Nội dung mô tả |
---|---|
Biến dành riêng cho nhà phát triển | |
developer.id |
|
developer.userName |
|
developer.firstName |
|
developer.lastName |
|
developer.email |
|
developer.status |
đang hoạt động hoặc không hoạt động |
developer.apps |
|
developer.created_by |
|
developer.created_at |
|
developer.last_modified_at |
|
developer.last_modified_by |
|
developer.{custom_attributes} |
Thuộc tính tuỳ chỉnh được đặt tên của nhà phát triển. |
Biến dành riêng cho công ty
Nếu app.appType là "Company", thì thuộc tính của công ty sẽ được điền và nếu app.appType là "Nhà phát triển", thì thuộc tính của nhà phát triển sẽ được điền.
Biến | Nội dung mô tả |
---|---|
company.id |
|
company.displayName |
|
company.apps |
|
company.appOwnerStatus |
|
company.created_by |
|
company.created_at |
|
company.last_modified_at |
|
company.last_modified_by |
|
company.{custom_attributes} |
Thuộc tính tuỳ chỉnh được đặt tên của công ty. |
Thao tác generateAuthorizeCode
Các biến này được thiết lập khi thao tác GenerateAuthorizeCode thực thi thành công:
Tiền tố: oauthv2authcode.{policy_name}.{variable_name}
Ví dụ: oauthv2authcode.GenerateCodePolicy.code
Biến | Nội dung mô tả |
---|---|
code |
Mã uỷ quyền được tạo khi chính sách này thực thi. |
redirect_uri |
URI chuyển hướng được liên kết với ứng dụng khách đã đăng ký. |
scope |
Phạm vi OAuth không bắt buộc được chuyển trong yêu cầu ứng dụng. |
client_id |
Mã ứng dụng được truyền trong yêu cầu ứng dụng. |
Các hoạt động GenerateAccessToken và RefreshAccessToken
Các biến này được thiết lập khi các tác vụ GenerateAccessToken và RefreshAccessToken thực thi thành công. Xin lưu ý rằng các biến mã thông báo làm mới không áp dụng cho quy trình loại cấp thông tin đăng nhập ứng dụng.
Tiền tố: oauthv2accesstoken.{policy_name}.{variable_name}
Ví dụ: oauthv2accesstoken.GenerateTokenPolicy.access_token
Tên biến | Nội dung mô tả |
---|---|
access_token |
Mã truy cập đã được tạo. |
client_id |
Mã ứng dụng khách của ứng dụng của nhà phát triển được liên kết với mã thông báo này. |
expires_in |
Giá trị hết hạn của mã thông báo. Hãy xem phần tử <ExpiresIn> để biết thông tin chi tiết. Lưu ý rằng trong phản hồi, expires_in được biểu thị bằng giây. |
scope |
Danh sách các phạm vi có thể sử dụng đã định cấu hình cho mã thông báo. Xem phần Làm việc với phạm vi OAuth2. |
status |
approved hoặc revoked . |
token_type |
Đã đặt thành BearerToken . |
developer.email |
Địa chỉ email của nhà phát triển đã đăng ký và sở hữu ứng dụng của nhà phát triển được liên kết với mã thông báo đó. |
organization_name |
Tổ chức nơi proxy thực thi. |
api_product_list |
Danh sách sản phẩm liên kết với ứng dụng dành cho nhà phát triển tương ứng của mã thông báo. |
refresh_count |
|
refresh_token |
Mã làm mới đã được tạo. Xin lưu ý rằng mã thông báo làm mới không được tạo cho loại cấp thông tin đăng nhập ứng dụng. |
refresh_token_expires_in |
Thời gian tồn tại của mã làm mới, tính bằng giây. |
refresh_token_issued_at |
Giá trị thời gian này là chuỗi đại diện cho số lượng dấu thời gian 32 bit tương ứng. Ví dụ: "Thứ Tư, ngày 21 tháng 8 năm 2013 19:16:47 giờ UTC" tương ứng với giá trị dấu thời gian là 1377112607413. |
refresh_token_status |
approved hoặc revoked . |
GenerateAccessTokenImplicitGrant
Các biến này được đặt khi thao tác GenerateAccessTokenOverride thực thi thành công cho luồng loại cấp quyền ngầm ẩn.
Tiền tố: oauthv2accesstoken.{policy_name}.{variable_name}
Ví dụ: oauthv2accesstoken.RefreshTokenPolicy.access_token
Biến | Nội dung mô tả |
---|---|
oauthv2accesstoken.access_token |
Mã truy cập được tạo khi chính sách này thực thi. |
oauthv2accesstoken.{policy_name}.expires_in |
Giá trị hết hạn của mã thông báo, tính bằng giây. Hãy xem phần tử <ExpiresIn> để biết thông tin chi tiết. |
Tham chiếu lỗi
Phần này mô tả các mã lỗi và thông báo lỗi được trả về, cũng như các biến lỗi do Edge đặt khi chính sách này kích hoạt lỗi. Thông tin này đóng vai trò quan trọng trong việc phát triển các quy tắc lỗi để xử lý lỗi. Để tìm hiểu thêm, hãy xem Những điều bạn cần biết về lỗi chính sách và Xử lý lỗi.
Lỗi thời gian chạy
Những lỗi này có thể xảy ra khi thực thi chính sách.
Mã lỗi | Trạng thái HTTP | Nguyên nhân | Gửi theo toán tử |
---|---|---|---|
steps.oauth.v2.access_token_expired |
401 | Mã truy cập đã hết hạn. |
VerifyAccessToken |
steps.oauth.v2.access_token_not_approved |
401 | Mã truy cập đã bị thu hồi. | VerifyAccessToken |
steps.oauth.v2.apiresource_doesnot_exist |
401 | Tài nguyên được yêu cầu không tồn tại bất kỳ sản phẩm API nào được liên kết với mã truy cập. | VerifyAccessToken |
steps.oauth.v2.FailedToResolveAccessToken |
500 | Chính sách dự kiến tìm thấy mã truy cập trong một biến được chỉ định ở phần tử <AccessToken> , nhưng không thể phân giải biến đó. |
GenerateAccessToken |
steps.oauth.v2.FailedToResolveAuthorizationCode |
500 | Chính sách dự kiến tìm thấy mã uỷ quyền trong một biến được chỉ định ở phần tử <Code> , nhưng không thể phân giải biến đó. |
GenerateAuthorizationCode |
steps.oauth.v2.FailedToResolveClientId |
500 | Chính sách dự kiến tìm thấy Mã ứng dụng khách trong một biến được chỉ định ở phần tử <ClientId> , nhưng biến đó không phân giải được. |
CreateAccessToken GenerateAuthCode GenerateAccessTokenimplicitGrant RefreshAccessToken |
steps.oauth.v2.FailedToResolveRefreshToken |
500 | Chính sách dự kiến sẽ tìm thấy mã làm mới trong một biến được chỉ định ở phần tử <RefreshToken> , nhưng không phân giải được biến đó. |
RefreshAccessToken |
steps.oauth.v2.FailedToResolveToken |
500 | Chính sách dự kiến tìm thấy mã thông báo trong một biến được chỉ định ở phần tử <Tokens> , nhưng không thể phân giải biến đó. |
ValidationToken |
steps.oauth.v2.InsufficientScope |
403 | Mã truy cập thể hiện trong yêu cầu có phạm vi không khớp với phạm vi đã chỉ định trong chính sách về mã truy cập xác minh. Để tìm hiểu về phạm vi, hãy xem bài viết Làm việc với phạm vi OAuth2. | VerifyAccessToken |
steps.oauth.v2.invalid_access_token |
401 | Mã truy cập do ứng dụng gửi là không hợp lệ. | VerifyAccessToken |
steps.oauth.v2.invalid_client |
401 |
Tên lỗi này được trả về khi thuộc tính Lưu ý: Bạn nên thay đổi các điều kiện của quy tắc lỗi hiện có để nắm bắt cả tên |
CreateAccessToken RefreshAccessToken |
steps.oauth.v2.invalid_request |
400 | Tên lỗi này dùng cho nhiều loại lỗi, thường là cho các tham số bị thiếu hoặc không chính xác được gửi trong yêu cầu. Nếu bạn đặt <GenerateResponse> thành false , hãy sử dụng các biến lỗi (như mô tả bên dưới) để truy xuất thông tin chi tiết về lỗi, chẳng hạn như tên lỗi và nguyên nhân. |
CreateAccessToken GenerateAuthCode GenerateAccessTokenimplicitGrant RefreshAccessToken |
steps.oauth.v2.InvalidAccessToken |
401 | Tiêu đề uỷ quyền không có từ bắt buộc phải có từ "Bearer". Ví dụ: Authorization: Bearer your_access_token |
VerifyAccessToken |
steps.oauth.v2.InvalidAPICallAsNo\ |
401 |
Proxy API không nằm trong Sản phẩm được liên kết với mã truy cập. Lưu ý: Đảm bảo rằng sản phẩm liên kết với mã truy cập được định cấu hình đúng cách. Ví dụ: nếu bạn sử dụng ký tự đại diện trong đường dẫn tài nguyên, hãy đảm bảo bạn sử dụng ký tự đại diện đúng cách. Xem bài viết Tạo sản phẩm API để biết thông tin chi tiết. Hãy xem thêm bài đăng này trên thẻ Cộng đồng Apigee để biết thêm hướng dẫn về nguyên nhân gây ra lỗi này. |
VerifyAccessToken |
steps.oauth.v2.InvalidClientIdentifier |
500 |
Tên lỗi này được trả về khi thuộc tính |
CreateAccessToken |
steps.oauth.v2.InvalidParameter |
500 | Chính sách phải chỉ định mã truy cập hoặc mã uỷ quyền, nhưng không được chỉ định cả hai. | Tạo thư ủy quyền |
steps.oauth.v2.InvalidTokenType |
500 | Phần tử <Tokens>/<Token> yêu cầu bạn chỉ định loại mã thông báo (ví dụ: refreshtoken ). Nếu ứng dụng truyền không đúng loại, lỗi này sẽ được gửi ra. |
ValidationToken InvalidateToken |
steps.oauth.v2.MissingParameter |
500 | Loại phản hồi là token , nhưng không có loại cấp quyền nào được chỉ định. |
Tạo thư ủy quyền |
steps.oauth.v2.UnSupportedGrantType |
500 |
Khách hàng đã chỉ định một loại tài trợ mà chính sách không hỗ trợ (không có trong phần tử <SupportedGrantTypes>). Lưu ý: Hiện tại có một lỗi trong đó lỗi loại cấp không được hỗ trợ không được gửi chính xác. Nếu xảy ra lỗi loại cấp không được hỗ trợ, thì proxy sẽ không nhập Luồng lỗi như dự kiến. |
CreateAccessToken GenerateAuthCode GenerateAccessTokenimplicitGrant RefreshAccessToken |
Lỗi triển khai
Những lỗi này có thể xảy ra khi bạn triển khai proxy chứa chính sách này.
Tên lỗi | Nguyên nhân |
---|---|
InvalidValueForExpiresIn |
Đối với phần tử |
InvalidValueForRefreshTokenExpiresIn |
Đối với phần tử <RefreshTokenExpiresIn> , các giá trị hợp lệ là số nguyên dương và -1 . |
InvalidGrantType |
Loại cấp quyền không hợp lệ được chỉ định trong phần tử <SupportedGrantTypes> . Hãy xem tài liệu tham khảo chính sách để biết danh sách các loại hợp lệ. |
ExpiresInNotApplicableForOperation |
Hãy đảm bảo rằng các thao tác được chỉ định trong phần tử hỗ trợ phần tử <Operations> đã hết hạn. Ví dụ: thao tác VerifyToken thì không. |
RefreshTokenExpiresInNotApplicableForOperation |
Hãy đảm bảo rằng các thao tác được chỉ định trong phần tử <Operations> hỗ trợ thời hạn của mã làm mới. Ví dụ: thao tác VerifyToken thì không. |
GrantTypesNotApplicableForOperation |
Hãy đảm bảo rằng các loại tài trợ được chỉ định trong <SupportedGrantTypes> được hỗ trợ cho hoạt động đã chỉ định. |
OperationRequired |
Bạn phải chỉ định một thao tác trong chính sách này bằng phần tử Lưu ý: Nếu phần tử |
InvalidOperation |
Bạn phải chỉ định một thao tác hợp lệ trong chính sách này bằng phần tử Lưu ý: Nếu phần tử |
TokenValueRequired |
Bạn phải chỉ định giá trị mã thông báo <Token> trong phần tử <Tokens> . |
Biến lỗi
Các biến này được đặt khi chính sách này kích hoạt lỗi trong thời gian chạy.
<GenerateResponse>
thành false
. Nếu <GenerateResponse>
là true
, chính sách này sẽ trả về phản hồi cho ứng dụng ngay lập tức trong trường hợp xảy ra lỗi – quy trình lỗi sẽ bị bỏ qua và các biến này không được điền sẵn. Để biết thêm thông tin, hãy xem phần Những điều bạn cần biết về lỗi chính sách.Biến | Trong đó | Ví dụ: |
---|---|---|
fault.name="fault_name" |
fault_name là tên của lỗi, như liệt kê trong bảng Lỗi thời gian chạy ở trên. Tên lỗi là phần cuối cùng của mã lỗi. | fault.name = "invalid_request" |
oauthV2.policy_name.failed |
policy_name là tên của chính sách báo lỗi do người dùng chỉ định. | oauthV2.GenerateAccesstoken.failed = true |
oauthV2.policy_name.fault.name |
policy_name là tên của chính sách báo lỗi do người dùng chỉ định. | oauthV2.GenerateAccesstoken.fault.name = invalid_request
Lưu ý: Đối với thao tác VerifyAccessToken, tên lỗi sẽ có hậu tố sau: |
oauthV2.policy_name.fault.cause |
policy_name là tên của chính sách báo lỗi do người dùng chỉ định. | oauthV2.GenerateAccesstoken.cause = Required param : grant_type |
Ví dụ về phản hồi lỗi
Các phản hồi này sẽ được gửi lại ứng dụng khách nếu phần tử <GenerateResponse>
là true.
errorcode
của phản hồi lỗi. Đừng dựa vào văn bản trong faultstring
vì văn bản này có thể thay đổi.Nếu <GenerateResponse>
là true, thì chính sách sẽ trả về các lỗi theo định dạng này cho các thao tác tạo mã thông báo và mã. Để biết danh sách đầy đủ, hãy xem Tài liệu tham khảo về phản hồi lỗi HTTP qua OAuth.
{"ErrorCode" : "invalid_client", "Error" :"ClientId is Invalid"}
Nếu <GenerateResponse>
là true (đúng), chính sách sẽ trả về các lỗi ở định dạng này để xác minh và xác thực các thao tác. Để biết danh sách đầy đủ, hãy xem Tài liệu tham khảo về phản hồi lỗi HTTP qua OAuth.
{ { "fault":{ "faultstring":"Invalid Access Token", "detail":{ "errorcode":"keymanagement.service.invalid_access_token" } } }
Ví dụ về quy tắc lỗi
<FaultRule name=OAuthV2 Faults"> <Step> <Name>AM-InvalidClientResponse</Name> <Condition>(fault.name = "invalid_client") OR (fault.name = "InvalidClientIdentifier")</Condition> </Step> <Step> <Name>AM-InvalidTokenResponse</Name> <Condition>(fault.name = "invalid_access_token")</Condition> </Step> <Condition>(oauthV2.failed = true) </Condition> </FaultRule>
Giản đồ chính sách
Mỗi loại chính sách được xác định bằng một giản đồ XML (.xsd
). Để tham khảo, lược đồ chính sách có trên GitHub.
Làm việc với cấu hình OAuth mặc định
Mỗi tổ chức (kể cả tổ chức dùng thử miễn phí) sử dụng Apigee Edge đều được cấp phép bằng một điểm cuối của mã thông báo OAuth. Điểm cuối được định cấu hình sẵn bằng các chính sách trong proxy API có tên là oauth. Bạn có thể bắt đầu sử dụng điểm cuối của mã thông báo ngay khi tạo tài khoản trên Apigee Edge. Để biết thông tin chi tiết, hãy xem bài viết Tìm hiểu về điểm cuối của OAuth.
Xoá mã truy cập
Theo mặc định, mã thông báo OAuth2 sẽ bị xoá hoàn toàn khỏi hệ thống Apigee Edge sau 3 ngày (259200 giây) sau khi cả mã truy cập và mã làm mới (nếu có) hết hạn. Trong một số trường hợp, bạn có thể cần thay đổi giá trị mặc định này. Ví dụ: bạn nên rút ngắn thời gian xoá hoàn toàn để tiết kiệm dung lượng ổ đĩa nếu có một số lượng lớn mã thông báo đang được tạo.
Nếu đang dùng Edge for Private Cloud, bạn có thể thay đổi chế độ mặc định này bằng cách đặt các thuộc tính tổ chức như giải thích trong phần này. (Tính năng xoá hoàn toàn các mã thông báo đã hết hạn trong vòng 3 ngày sẽ áp dụng cho Edge for Private Cloud phiên bản 4.19.01 trở lên. Đối với các phiên bản cũ, khoảng thời gian xoá hoàn toàn mặc định là 180 ngày.)
Cập nhật các tùy chọn cài đặt xóa hoàn toàn cho Edge Private Cloud 4.16.01 trở lên
Lưu ý: Chỉ những mã thông báo được tạo sau khi áp dụng những chế độ cài đặt này mới bị ảnh hưởng; các chế độ cài đặt này không áp dụng cho những mã thông báo đã tạo trước đó.
- Mở tệp này để chỉnh sửa:
/opt/apigee/customer/application/message-processor.properties
- Thêm thuộc tính sau để đặt số giây cần chờ trước khi xoá hoàn toàn mã thông báo sau khi mã hết hạn:
conf_keymanagement_oauth.access.token.purge.after.seconds=<number of seconds>
- Khởi động lại trình xử lý thư. Ví dụ:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
<ExpiresIn>
và <RefreshTokenExpiresIn>
.
Cập nhật các tùy chọn cài đặt xoá hoàn toàn cho Edge Private Cloud 4.15.07
Lưu ý: Chỉ những mã thông báo được tạo sau khi áp dụng những chế độ cài đặt này; chế độ cài đặt này không áp dụng cho những mã thông báo đã tạo trước đó.
-
Đặt giá trị dương cho các thuộc tính
<ExpiresIn>
và<RefreshTokenExpiresIn>
trong chính sách OAuthV2. Các giá trị được tính bằng mili giây. Ví dụ:<ExpiresIn>1000</ExpiresIn> <RefreshTokenExpiresIn>10000</RefreshTokenExpiresIn>
-
Triển khai lại proxy.
-
Hãy dùng API này để cập nhật các thuộc tính xoá hoàn toàn mã thông báo cho tổ chức của bạn:
POST https://<host-name>/v1/organizations/<org-name>
Tải trọng:
<Organization name="AutomationOrganization"> <Description>Desc</Description> <Properties> <Property name="keymanagement.oauth20.access.token.purge">true</Property> <Property name="keymanagement.oauth20.access.token.purge.after.seconds">120</Property> </Properties> </Organization>
-
Khởi động lại trình xử lý thư. Ví dụ:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
API này thiết lập thuộc tính xoá hoàn toàn mã thông báo thành true cho tổ chức có tên là automatedOrganization. Trong trường hợp này, mã truy cập sẽ bị xoá hoàn toàn khỏi cơ sở dữ liệu sau 120 giây kể từ khi cả mã thông báo và mã làm mới hết hạn.
Hành vi không tuân thủ RFC
Chính sách OAuthV2 sẽ trả về phản hồi mã thông báo có chứa một số thuộc tính không tuân thủ RFC. Bảng sau đây cho thấy các thuộc tính không tuân thủ do chính sách OAuthV2 trả về và các thuộc tính tuân thủ tương ứng.
Trả về OAuthV2: | Thuộc tính tuân thủ RFC là: |
---|---|
"token_type":"BearerToken" |
"token_type":"Bearer"
|
"expires_in":"3600" |
"expires_in":3600
(Giá trị tuân thủ là một số, không phải là một chuỗi.) |
Ngoài ra, phản hồi lỗi cho mã thông báo làm mới đã hết hạn khi grant_type = refresh_token
là:
{"ErrorCode" : "invalid_request", "Error" :"Refresh Token expired"}
Tuy nhiên, phản hồi tuân thủ RFC là:
{"error" : "invalid_grant", "error_description" :"refresh token expired"}