Triển khai kiểu cấp mã uỷ quyền

Bạn đang xem tài liệu về Apigee Edge.
Chuyển đến Tài liệu về Apigee X.
thông tin

Mã uỷ quyền là một trong những loại cấp quyền OAuth 2.0 thường được dùng nhất. Khoản uỷ quyền luồng mã là một "OAuth ba bên" . Trong cấu hình này, người dùng xác thực với máy chủ tài nguyên và đồng ý cho ứng dụng truy cập vào các tài nguyên được bảo vệ của họ mà không cần tiết lộ tên người dùng/mật khẩu 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à thông tin tổng quan về loại cấp quyền uỷ quyền OAuth 2.0 và thảo luận về cách triển khai quy trình này trên Apigee Edge.

Video

Xem video ngắn để tìm hiểu cách sử dụng loại cấp quyền uỷ quyền OAuth 2.0 để bảo mật API của bạn.

Trường hợp sử dụng

Loại quyền này dành cho các ứng dụng do nhà phát triển bên thứ ba viết nhưng không có mối quan hệ kinh doanh đáng tin cậy với nhà cung cấp API. Ví dụ: những nhà phát triển đăng ký cho các chương trình API công khai thường không đáng tin cậy. Với loại quyền này, thông tin xác thực trên máy chủ tài nguyên không bao giờ được chia sẻ với ứng dụng.

Mã mẫu

Bạn có thể tìm thấy cách triển khai mẫu hoàn chỉnh, đang hoạt động của loại cấp mã uỷ quyền trên Apigee Edge trong kho lưu trữ api-platform-samples trên GitHub. Xem OAuth-advanced mẫu trong thư mục api-platform-samples/sample-proxies. Hãy xem README để biết thông tin chi tiết về mẫu.

Sơ đồ quy trình

Sơ đồ quy trình sau minh hoạ quy trình OAuth của mã uỷ quyền thông qua Apigee Edge đóng vai trò là máy chủ uỷ quyền.

Mẹo: Để xem phiên bản lớn hơn của sơ đồ này, hãy nhấp chuột phải vào biểu đồ rồi mở trong thẻ mới hoặc lưu và mở thẻ mới trong trình xem hình ảnh.

Các bước trong quy trình mã uỷ quyền

Dưới đây là phần tóm tắt các bước bắt buộc để triển khai loại cấp mã uỷ quyền trong đó Apigee Edge đóng vai trò là máy chủ uỷ quyền. Hãy nhớ, chìa khoá của quy trình này là khách hàng không bao giờ xem được thông tin xác thực của người dùng trên máy chủ tài nguyên.

Điều kiện tiên quyết: Bạn phải đăng ký ứng dụng khách với Apigee Edge để lấy ID ứng dụng khách và khoá bí mật của ứng dụng khách. Xem phần Đăng ký ứng dụng khách để chi tiết.

1. Người dùng bắt đầu quy trình

Khi ứng dụng cần truy cập vào tài nguyên được bảo vệ của người dùng từ một máy chủ tài nguyên (cho ví dụ: danh bạ trên một trang mạng xã hội), ứng dụng này sẽ gửi lệnh gọi API đến Apigee Edge, xác thực ID của ứng dụng khách và nếu ID đó hợp lệ, sẽ chuyển hướng trình duyệt của người dùng đến trang đăng nhập tại đó người dùng sẽ nhập thông tin đăng nhập của họ. Lệnh gọi API bao gồm thông tin mà ứng dụng khách lấy được khi được đăng ký: ID ứng dụng khách và URI chuyển hướng.

2. Người dùng nhập thông tin đăng nhập

Giờ đây, người dùng sẽ thấy trang đăng nhập để yêu cầu họ nhập thông tin đăng nhập. Nếu đăng nhập thành công, chúng ta chuyển sang bước tiếp theo.

3. Người dùng đồng ý

Ở bước này, người dùng đồng ý cho phép ứng dụng truy cập vào tài nguyên của họ. Biểu mẫu đồng ý thường bao gồm các lựa chọn phạm vi, trong đó người dùng có thể chọn những việc ứng dụng được phép thực hiện máy chủ tài nguyên. Ví dụ: người dùng có thể cấp quyền chỉ có thể đọc hoặc quyền cho ứng dụng để cập nhật tài nguyên.

4. Ứng dụng đăng nhập gửi yêu cầu Apigee Edge

Nếu đăng nhập và đồng ý thành công, ứng dụng đăng nhập sẽ POST dữ liệu vào /authorizedcode điểm cuối của Apigee Edge. Dữ liệu này bao gồm URI chuyển hướng, mã ứng dụng khách, phạm vi, mọi thuộc tính dành riêng cho người dùng thông tin mà tên miền đó muốn bao gồm và một dấu hiệu cho biết đăng nhập đã thành công.

5. Ứng dụng Apigee Edge sẽ tạo một mã uỷ quyền

Khi Edge nhận được yêu cầu GET từ ứng dụng đăng nhập trên điểm cuối /uỷ quyền mã, hai mọi thứ xảy ra. Đầu tiên, Edge xác định rằng đăng nhập đã thành công (bằng cách kiểm tra trạng thái HTTP hoặc một số phương tiện khác). Next Edge sẽ kiểm tra để đảm bảo rằng URI chuyển hướng được gửi từ ứng dụng đăng nhập khớp với URI chuyển hướng được chỉ định khi đăng ký ứng dụng với Apigee Edge. Nếu mọi thứ đều ổn, Edge sẽ tạo một mã uỷ quyền. Ví dụ:

http://myorg-test.apigee.net/oauth/authorizationcode?client_id={consumer_key}&response_type=code&redirect_uri={redirect_uri}&scope=scope1%20scope2&state={some_string}

6. Cạnh gửi mã uỷ quyền trở lại máy khách

Edge gửi lệnh chuyển hướng 302 kèm theo mã xác thực dưới dạng tham số truy vấn đến khách hàng.

7. Ứng dụng truy xuất mã uỷ quyền và yêu cầu Edge cấp mã truy cập

Giờ đây, khi có mã xác thực hợp lệ, ứng dụng có thể yêu cầu mã truy cập từ Edge. Công cụ này thực hiện việc này bằng cách POST ID ứng dụng khách và khoá bí mật của ứng dụng khách (lấy khi ứng dụng được đăng ký trên Edge), loại tài trợ và phạm vi tài trợ. Bằng cách cung cấp mã ứng dụng khách và khoá bí mật, Apigee Edge có thể xác minh rằng ứng dụng khách là ứng dụng đã được đăng ký. Ví dụ:

$ curl https://{org_name}-test.apigee.net/my_oauth_proxy/accesstoken?code=Xyz123&grant_type=authorization_code -X POST -d 'client_id=bBGAQrXgivA9lKu7NMPyoYpKNhGar6K&client_secret=hAr4GngA9vAyvI4'

8. Khách hàng nhận được mã truy cập

Nếu mọi thứ đều thành công, Edge sẽ trả về một mã truy cập cho ứng dụng. Mã truy cập sẽ có ngày hết hạn và sẽ chỉ hợp lệ trong phạm vi mà người dùng chỉ định khi họ cung cấp đồng ý cho ứng dụng truy cập vào tài nguyên của họ.

9. Khách hàng gọi API được bảo vệ

Giờ đây, khi có mã truy cập hợp lệ, ứng dụng có thể thực hiện lệnh gọi đến API được bảo vệ. Trong phần này Trong trường hợp này, yêu cầu được gửi đến Apigee Edge (máy chủ proxy) và Edge sẽ chịu trách nhiệm xác thực mã truy cập trước khi truyền lệnh gọi API đến máy chủ tài nguyên mục tiêu. Mã truy cập được chuyển vào tiêu đề Uỷ quyền. Ví dụ:

$ curl -H "Authorization: Bearer ylSkZIjbdWybfs4fUQe9BqP0LH5Z" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282

Định cấu hình quy trình và chính sách

Là máy chủ uỷ quyền, Edge cần xử lý một số yêu cầu OAuth: để có quyền truy cập mã thông báo, mã xác thực, mã làm mới, chuyển hướng trang đăng nhập, v.v. Có hai bước cơ bản để định cấu hình các điểm cuối này:

  • Tạo flow tuỳ chỉnh
  • Thêm và định cấu hình các chính sách OAuthV2

Cấu hình luồng tuỳ chỉnh

Bạn thường định cấu hình quy trình loại cấp quyền này sao cho mỗi bước hoặc "chân" của luồng được xác định thông qua một luồng trong proxy Apigee Edge. Mỗi quy trình có một điểm cuối và một chính sách thực hiện Bạn cần thực hiện một thao tác liên quan đến OAuth, chẳng hạn như tạo mã uỷ quyền hoặc mã truy cập. Cho ví dụ như minh hoạ trong XML dưới đây, điểm cuối /oauth/authorizationcode có chính sách được liên kết có tên GenerateAuthCode (là chính sách OAuthV2 có phần tử Đã chỉ định hoạt động GeneratePermissionCode).

Cách dễ nhất để hiển thị cấu hình luồng là sử dụng ví dụ XML. Xem nội tuyến nhận xét để biết thông tin về từng quy trình. Đây là ví dụ -- tên của luồng và đường dẫn có thể được định cấu hình theo cách bạn muốn. Xem thêm bài viết Định cấu hình OAuth điểm cuối và chính sách để xem 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.

Xem thêm ví dụ triển khai trên GitHub.

<Flows>
<Flow name="RedirectToLoginApp">
<!--
Publish this URI to developers to use for their 'login' link
-->
<Condition>proxy.pathsuffix == "/oauth/authorize"</Condition>
<Request>
<Step><Name>RedirectToLoginPage</Name></Step>
</Request>
</Flow>
<Flow name="GetAuthCode">
<!--
Call this URL from your Login app after you authenticate the user.
The policy will automatically return the auth code in the response to the
redirect_uri registered by the calling app
-->
<Condition>proxy.pathsuffix == "/oauth/authorizationcode"</Condition>
<Request>
<Step><Name>GenerateAuthCode</Name></Step>
</Request>
</Flow>
<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>GenerateAccessToken</Name></Step>
</Request>
</Flow>
</Flows>

Định cấu hình các quy trình có chính sách

Mỗi điểm cuối đều được liên kết với một chính sách. Hãy cùng xem ví dụ về các chính sách đó. Xem cả Định cấu hình OAuth các điểm cuối và chính sách để xem thông tin tổng quan nhanh về các bước cần thiết để thêm chính sách OAuthV2 đến điểm cuối proxy.

Chuyển hướng đăng nhập

Đây là đường dẫn /oauth/authorize. Chính sách đính kèm chịu trách nhiệm về chuyển hướng người dùng đến ứng dụng đăng nhập, trong đó người dùng cuối có thể xác thực và uỷ quyền một cách an toàn ứng dụng khách để truy cập vào tài nguyên được bảo vệ của họ mà không cần tiết lộ tên người dùng và mật khẩu để ứng dụng khách. Bạn có thể thực hiện việc này bằng chính sách chú thích dịch vụ, JavaScript, Node.js hoặc phương tiện khác.

Lệnh gọi API để thực hiện yêu cầu là một GET và yêu cầu tham số truy vấn client_id, response_type, chuyển hướng_uri, phạm vi và trạng thái.

$ curl http://myorg-test.apigee.net/oauth/authorize?client_id={consumer_key}&response_type=code&redirect_uri={redirect_uri}&scope=scope1%20scope2&state={some_string}

Nhận mã uỷ quyền

Đây là đường dẫn /oauth/authorizationcode. URL này sử dụng chính sách OAuthV2 với Đã chỉ định hoạt động Generateuỷ quyền.

<OAuthV2 async="false" continueOnError="false" enabled="true" name="GetAuthCode">
    <DisplayName>GetAuthCode</DisplayName>
    <Operation>GenerateAuthorizationCode</Operation>
    <ExpiresIn>600000</ExpiresIn>
    <GenerateResponse/>
</OAuthV2>

Lệnh gọi API để lấy mã uỷ quyền là một phương thức GET và yêu cầu tham số truy vấn client_id, response_type, cũng như phạm vi và trạng thái (không bắt buộc) như trong ví dụ sau:

$curl http://myorg-test.apigee.net/oauth/authorizationcode?client_id={consumer_key}&response_type=code&scope=scope1%20scope2&state={some_string}

Nhận mã truy cập

Chính sách này được đính kèm với đường dẫn /oauth/accesstoken. Phương thức này sử dụng OAuthV2 chính sách có hoạt động GenerateAccessCode được chỉ định. Trong trường hợp này, thông số enable_type sẽ là được mong đợi dưới dạng tham số truy vấn:

<OAuthV2 name="GetAccessToken">
    <Operation>GenerateAccessToken</Operation>
    <ExpiresIn>360000000</ExpiresIn> 
    <SupportedGrantTypes> 
        <GrantType>authorization_code</GrantType> 
    </SupportedGrantTypes> 
    <GrantType>request.queryparam.grant_type</GrantType> 
    <GenerateResponse/> 
</OAuthV2>

Lệnh gọi API để lấy mã truy cập là một POST và phải bao gồm client_id, client_secret, Grants_type=Proxy_code và phạm vi (không bắt buộc). Ví dụ:

$ curl https://{org_name}-test.apigee.net/oauth/accesstoken?grant_type=authorization_code -X POST -d 'client_id=bBGAQrXgivA9lKu7NMPyoYpVKNhGar6K&client_secret=hAr4Gn0gA9vAyvI4'

Đây chỉ là bản tóm tắt cơ bản. Ví dụ về sản xuất bao gồm nhiều chính sách khác về việc xây dựng URL, thực hiện các phép biến đổi và thực hiện các nhiệm vụ khác. Tham khảo mẫu trên GitHub để biết dự án hoàn thành, đang hoạt động.

Đính kèm chính sách về mã truy cập xác minh

Đính kèm một chính sách VerifyAccessToken (chính sách OAuthV2 với thao tác VerifyAccessToken đã chỉ định) vào đầu bất kỳ flow nào truy cập vào API được bảo vệ để API đó được thực thi bất cứ khi nào có yêu cầu về tài nguyên được bảo vệ. Kiểm tra cạnh để đảm bảo mỗi yêu cầu có một mã truy cập hợp lệ. Nếu không, hệ thống sẽ trả về lỗi. Để biết các bước cơ bản, hãy xem bài viết 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 cung cấp quyền truy cập hợp lệ mã thông báo. Mẫu chính xác là đưa mã thông báo vào tiêu đề Uỷ quyền như sau: Lưu ý mã truy cập này còn được gọi là "mã thông báo truy cập".

$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \
  http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282 

Hãy xem thêm phần Gửi mã truy cập.