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
Với loại cấp thông tin đăng nhập của ứng dụng khách, một ứng dụng sẽ gửi thông tin đăng nhập của chính mình (Mã ứng dụng khách và Khoá bí mật của ứng dụng khách) đến một điểm cuối trên Apigee Edge được thiết lập để tạo mã truy cập. Nếu thông tin đăng nhập hợp lệ, Edge sẽ trả về mã truy cập cho ứng dụng khách.
Giới thiệu về chủ đề này
Chủ đề này cung cấp nội dung mô tả chung về loại cấp thông tin đăng nhập của ứng dụng OAuth 2.0 và thảo luận về cách triển khai quy trình này trên Apigee Edge.
Trường hợp sử dụng
Thông thường nhất, loại cấp phép này được dùng khi ứng dụng cũng là chủ sở hữu tài nguyên. Ví dụ: một ứng dụng có thể cần truy cập vào dịch vụ lưu trữ phụ trợ dựa trên đám mây để lưu trữ và truy xuất dữ liệu mà ứng dụng đó dùng để thực hiện công việc, thay vì dữ liệu thuộc sở hữu riêng của người dùng cuối. Quy trình cấp loại này diễn ra hoàn toàn giữa một ứng dụng khách và máy chủ uỷ quyền. Người dùng cuối không tham gia vào quy trình loại cấp quyền này.
Vai trò
Vai trò chỉ định "tác nhân" tham gia vào quy trình OAuth. Hãy xem nhanh thông tin tổng quan về các vai trò của thông tin đăng nhập của ứng dụng khách để minh hoạ vị trí của Apigee Edge. Để biết thông tin đầy đủ về các vai trò của OAuth 2.0, hãy xem quy cách OAuth 2.0 của IETF.
- Ứng dụng khách – Ứng dụng cần quyền truy cập vào các tài nguyên được bảo vệ của người dùng. Thông thường, với quy trình này, ứng dụng sẽ chạy trên máy chủ thay vì chạy cục bộ trên máy tính xách tay hoặc thiết bị của người dùng.
- Apigee Edge – Trong quy trình này, Apigee Edge là máy chủ uỷ quyền OAuth. Vai trò của máy chủ này là tạo mã truy cập, xác thực mã truy cập và chuyển các yêu cầu được uỷ quyền đối với tài nguyên được bảo vệ cho máy chủ tài nguyên.
- Máy chủ tài nguyên – Dịch vụ phụ trợ lưu trữ dữ liệu được bảo vệ mà ứng dụng khách cần có quyền truy cập. Nếu bạn đang bảo vệ các proxy API được lưu trữ trên Apigee Edge, thì Apigee Edge cũng là máy chủ tài nguyên.
Mã mẫu
Bạn có thể tìm thấy một mẫu triển khai hoàn chỉnh và hoạt động của loại cấp thông tin đăng nhập của ứng dụng trên GitHub. Hãy xem phần Tài nguyên bổ sung bên dưới để biết các đường liên kết đến nhiều ví dụ khác.
Sơ đồ luồng
Sơ đồ quy trình sau đây minh hoạ quy trình thông tin đăng nhập của ứng dụng khách với Apigee Edge đóng vai trò là máy chủ uỷ quyền. Nhìn chung, Edge cũng là máy chủ tài nguyên trong quy trình này – tức là các proxy API là tài nguyên được bảo vệ.
Các bước trong quy trình thông tin đăng nhập của ứng dụng
Sau đây là bản tóm tắt các bước cần thiết để triển khai loại cấp mã thông tin đăng nhập của ứng dụng khách, trong đó Apigee Edge đóng vai trò là máy chủ uỷ quyền. Xin lưu ý rằng với quy trình này, ứng dụng khách chỉ cần trình bày mã ứng dụng khách và khoá bí mật của ứng dụng khách. Nếu các mã này hợp lệ, Apigee Edge sẽ trả về một mã truy cập.
Điều kiện tiên quyết: Ứng dụng khách phải được đăng ký với Apigee Edge để lấy khoá mã ứng dụng khách và khoá bí mật của ứng dụng khách. Hãy xem phần Đăng ký ứng dụng khách để biết thông tin chi tiết.
1. Ứng dụng khách yêu cầu mã truy cập
Để nhận mã truy cập, ứng dụng sẽ gửi một lệnh gọi API đến Edge cùng với các giá trị cho mã ứng dụng và khoá bí mật của ứng dụng lấy từ một ứng dụng nhà phát triển đã đăng ký. Ngoài ra, bạn phải truyền tham số grant_type=client_credentials dưới dạng tham số truy vấn. (Tuy nhiên, bạn có thể định cấu hình chính sách OAuthV2 để chấp nhận tham số này trong tiêu đề của yêu cầu hoặc nội dung yêu cầu – hãy xem chính sách OAuthV2 để biết thông tin chi tiết).
Ví dụ:
$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' -X POST 'https://docs-test.apigee.net/oauth/accesstoken' -d 'grant_type=client_credentials&client_id=ns4fQc14Zg4hKFCNaSzArVuwszX95X&client_secret=ZIjFyTsNgQNyxI'
Lưu ý: Mặc dù bạn có thể truyền các giá trị client_id và client_secret dưới dạng tham số truy vấn như minh hoạ ở trên, nhưng bạn nên truyền các giá trị này dưới dạng chuỗi được mã hoá theo URL base64 trong tiêu đề Uỷ quyền. Để làm việc này, bạn cần sử dụng một công cụ hoặc tiện ích mã hoá base64 để mã hoá 2 giá trị cùng nhau, có dấu hai chấm phân tách giữa chúng. Chẳng hạn như sau: aBase64EncodeFunction(clientidvalue:clientsecret). Vì vậy, ví dụ trên sẽ được mã hoá như sau:
result = aBase64EncodeFunction(ns4fQc14Zg4hKFCNaSzArVuwszX95X:ZIjFyTsNgQNyxI) // Note the colon separating the two values.
Kết quả của việc mã hoá base64 chuỗi trên là: bnM0ZlFjMTRaZzRoS0ZDTmFTekFyVnV3c3pYOTVYOlpJakZ5VHNOZ1FOeXhJOg==
Sau đó, hãy thực hiện yêu cầu mã thông báo như sau:
$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' -X POST 'https://docs-test.apigee.net/oauth/accesstoken' -d 'grant_type=client_credentials' -H 'Authorization: Basic bnM0ZlFjMTRaZzRoS0ZDTmFTekFyVnV3c3pYOTVYOlpJakZ5VHNOZ1FOeXhJOg=='
2. Edge xác thực thông tin đăng nhập
Xin lưu ý rằng lệnh gọi API được gửi đến điểm cuối /accesstoken. Điểm cuối này có một chính sách được đính kèm để xác thực thông tin đăng nhập của ứng dụng. Tức là chính sách này so sánh các khoá đã gửi với các khoá mà Apigee Edge đã tạo khi ứng dụng được đăng ký. Nếu bạn muốn tìm hiểu thêm về các điểm cuối OAuth trên Edge, hãy xem phần Định cấu hình các điểm cuối và chính sách OAuth.
3. Edge trả về một câu trả lời
Nếu thông tin đăng nhập hợp lệ, Edge sẽ trả về mã truy cập cho ứng dụng. Nếu không, hệ thống sẽ trả về lỗi.
4. Ứng dụng gọi API được bảo vệ
Giờ đây, với mã truy cập hợp lệ, ứng dụng có thể gọi API được bảo vệ. Trong trường hợp này, các yêu cầu được gửi đến Apigee Edge (proxy) và Edge chịu trách nhiệm xác thực mã truy cập trước khi chuyển lệnh gọi API đến máy chủ tài nguyên đích. Để xem ví dụ, hãy xem phần Gọi API được bảo vệ bên dưới.
Định cấu hình luồng và chính sách
Là máy chủ uỷ quyền, Edge xử lý các yêu cầu về mã truy cập. Là nhà phát triển API, bạn cần tạo một proxy có quy trình tuỳ chỉnh để xử lý các yêu cầu về mã thông báo, đồng thời thêm và định cấu hình chính sách OAuthV2. Phần này giải thích cách định cấu hình điểm cuối đó.
Cấu hình quy trình tuỳ chỉnh
Cách dễ nhất để cho biết cách định cấu hình quy trình proxy API là cho biết định nghĩa quy trình XML. Sau đây là ví dụ về quy trình proxy API được thiết kế để xử lý yêu cầu mã truy cập. Ví dụ: khi một yêu cầu đến và hậu tố đường dẫn khớp với /accesstoken, chính sách GetAccessToken sẽ được kích hoạt. Hãy xem phần Định cấu hình các điểm cuối và chính sách OAuth để biết thông tin tổng quan nhanh về các bước cần thiết để tạo một quy trình tuỳ chỉnh như thế này.
<Flows>
<Flow name="GetAccessToken">
<!-- This policy flow is triggered when the URI path suffix
matches /oauth/accesstoken. Publish this URL to app developers
to use when obtaining an access token using an auth code
-->
<Condition>proxy.pathsuffix == "/oauth/accesstoken"</Condition>
<Request>
<Step><Name>GetAccessToken</Name></Step>
</Request>
</Flow>
</Flows>Định cấu hình quy trình bằng một chính sách
Bạn cần đính kèm một chính sách vào điểm cuối, như sau. Hãy xem phần Định cấu hình các điểm cuối và chính sách OAuth để biết thông tin tổng quan nhanh về các bước cần thiết để thêm chính sách OAuthV2 vào một điểm cuối của proxy.
Lấy mã truy cập
Chính sách này được đính kèm vào đường dẫn /accesstoken. Nó sử dụng chính sách OAuthV2 với thao tác GenerateAccessToken được chỉ định.
<OAuthV2 name="GetAccessToken">
<Operation>GenerateAccessToken</Operation>
<ExpiresIn>3600000</ExpiresIn>
<SupportedGrantTypes>
<GrantType>client_credentials</GrantType>
</SupportedGrantTypes>
<GenerateResponse/>
</OAuthV2>Lệnh gọi API để lấy mã truy cập là một lệnh gọi POST và có tiêu đề Uỷ quyền với client_id + client+secret được mã hoá base64 và tham số truy vấn grant_type=client_credentials. Bạn cũng có thể thêm các tham số không bắt buộc cho phạm vi và trạng thái. Ví dụ:
$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' -X POST 'https://docs-test.apigee.net/oauth/accesstoken' -d 'grant_type=client_credentials' -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAySVgT1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ'
Đính kèm chính sách xác minh mã truy cập
Để bảo vệ API bằng tính năng bảo mật OAuth 2.0, bạn cần thêm một chính sách OAuthV2 bằng thao tác VerifyAccessToken. Chính sách này kiểm tra để đảm bảo các yêu cầu đang chuyển đến có mã truy cập hợp lệ. Nếu mã thông báo hợp lệ, Edge sẽ xử lý yêu cầu. Nếu không hợp lệ, Edge sẽ trả về lỗi. Để biết các bước cơ bản, hãy xem phần Xác minh mã truy cập.
<OAuthV2 async="false" continueOnError="false" enabled="true" name="VerifyAccessToken">
<DisplayName>VerifyAccessToken</DisplayName>
<ExternalAuthorization>false</ExternalAuthorization>
<Operation>VerifyAccessToken</Operation>
<SupportedGrantTypes/>
<GenerateResponse enabled="true"/>
<Tokens/>
</OAuthV2>Gọi API được bảo vệ
Để gọi một API được bảo vệ bằng cơ chế bảo mật OAuth 2.0, bạn cần xuất trình một mã truy cập hợp lệ. Mẫu chính xác là đưa mã thông báo vào tiêu đề Uỷ quyền, như sau: Lưu ý rằng mã truy cập còn được gọi là "mã thông báo của người mang".
$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \ http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282
Xem thêm phần Gửi mã truy cập.
Tài nguyên khác
- Apigee cung cấp khoá đào tạo trực tuyến cho nhà phát triển API, bao gồm cả một khoá học về bảo mật API, trong đó có OAuth.
- Chính sách OAuthV2 – Có nhiều ví dụ cho thấy cách đưa ra yêu cầu đối với máy chủ uỷ quyền và cách định cấu hình chính sách OAuthV2.