Trang này được dịch bởi Cloud Translation API.

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 dùng nhất. Quy trình mã uỷ quyền là cấu hình " OAuth ba bên". Trong cấu hình này, người dùng tự xác thực với máy chủ tài nguyên và đồng ý cho ứng dụng truy cập vào tài nguyên được bảo vệ của họ mà không tiết lộ tên người dùng/mật khẩu cho ứng dụng.

Giới thiệu về chủ đề này

Chủ đề này đưa ra nội dung mô tả chung và thông tin tổng quan về quy trình cấp loại cấp quyền cho OAuth 2.0, đồng thời thảo luận 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 hình thức cấp phép OAuth 2.0 để bảo mật API.

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ý tham gia 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 của người dùng trên máy chủ tài nguyên sẽ 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 cho kiểu cấp mã uỷ quyền trên Apigee Edge trong kho lưu trữ api-platform-samples trên GitHub. Hãy xem mẫu OAuth-Nâng cao trong thư mục api-platform-samples/sample-proxies. Hãy xem tệp README để biết thông tin chi tiết về mẫu.

Sơ đồ quy trình

Sơ đồ quy trình sau đây minh hoạ quy trình OAuth của mã uỷ quyền, trong đó 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 một thẻ mới, hoặc lưu và mở trong một trình xem hình ảnh.

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

Sau đây là phần tóm tắt các bước cần thực hiện để triển khai hình thức cấp mã uỷ quyền, trong đó Apigee Edge đóng vai trò là máy chủ uỷ quyền. Hãy nhớ điều quan trọng đối với quy trình này là ứng dụ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 để có được mã ứng dụng khách và khoá bí mật của ứng dụng. Vui lòng xem phần Đăng ký ứng dụng khách để biết thông tin chi tiết.

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

Khi 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 (ví dụ: danh bạ trên trang mạng xã hội), ứng dụng sẽ gửi một lệnh gọi API đến Apigee Edge. Lệnh gọi này sẽ xác thực mã ứng dụng khách và chuyển hướng trình duyệt của người dùng đến một trang đăng nhập nơi người dùng sẽ nhập thông tin xác thực. Lệnh gọi API bao gồm thông tin mà ứng dụng khách lấy được khi đăng ký: mã ứ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 nhập thông tin đăng nhập. Nếu đăng nhập thành công, chúng ta sẽ chuyển sang bước tiếp theo.

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

Ở bước này, người dùng cho phép ứng dụng truy cập vào tài nguyên của họ. Biểu mẫu lấy sự đồ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 hành động mà ứng dụng được phép thực hiện trê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à yêu cầu đồng ý thành công, ứng dụng đăng nhập sẽ POST dữ liệu vào điểm cuối /uỷ quyền mã nguồn 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 thông tin theo từng người dùng cụ thể và chỉ báo đăng nhập thành công.

5. 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 /delegatecode, có hai sẽ xảy ra. Trước tiên, Edge xác định rằng lần đă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 thức 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 dụng được đăng ký bằng 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. Edge gửi lại mã uỷ quyền cho máy khách

Edge gửi một lệnh chuyển hướng 302 có đính kèm mã xác thực dưới dạng tham số truy vấn cho ứng dụng.

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

Giờ đây, với mã xác thực hợp lệ, ứng dụng có thể yêu cầu mã truy cập từ Edge. Trình phân tích cú pháp thực hiện việc này bằng cách ĐĂNG mã ứng dụng khách và khoá bí mật ứng dụng khách (thu được khi ứng dụng được đăng ký trên Edge), loại quyền và phạm vi cấp. Bằng cách thêm 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 này chính 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. Máy khách sẽ nhận được mã truy cập

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

9. Ứng dụ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 trường hợp này, các yêu cầu sẽ đượ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 chuyển lệnh gọi API đến máy chủ tài nguyên đích. 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: đối với mã truy cập, 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 luồng 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 luồng loại cấp quyền này để mỗi bước hoặc "chân" của luồng được xác định bằng 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 giúp thực hiện những tác vụ dành riêng cho OAuth, chẳng hạn như tạo mã uỷ quyền hoặc mã truy cập. Ví dụ: như minh hoạ trong tệp XML bên dưới, điểm cuối /oauth/authorizationcode có một chính sách liên kết có tên là GenerateAuthCode (đây là một chính sách OAuthV2 với thao tác GenerateCommitCode được chỉ định).

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

Hãy xem thêm ví dụ về cách 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 với chính sách

Mỗi điểm cuối được liên kết với một chính sách. Hãy xem ví dụ về các chính sách. Xem thêm bài viết Định cấu hình đ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 điểm cuối proxy.

Đây là đường dẫn /oauth/authorize. Chính sách đính kèm chịu trách nhiệm chuyển hướng người dùng đến một ứng dụng đăng nhập, trong đó người dùng cuối có thể xác thực và cho phép ứng dụng khách truy cập vào tài nguyên được bảo vệ một cách an toàn mà không tiết lộ tên người dùng và mật khẩu cho ứ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 các phương thức khác.

Lệnh gọi API để thực hiện yêu cầu là một phương thức GET và đòi hỏi các tham số truy vấn client_id, response_type, redirect_uri, scope và state.

$ 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ã xác thực

Đây là đường dẫn /oauth/authorizationcode. Thao tác này sử dụng chính sách OAuthV2 với thao tác GeneratevalidateCode được chỉ định.

<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à đòi hỏi phải có các 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ào đường dẫn /oauth/accesstoken. Phương thức này sử dụng chính sách OAuthV2 với thao tác GenerateAccessCode được chỉ định. Trong trường hợp này, thông số Grants_type sẽ được dự kiến là 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 yêu cầu POST và phải bao gồm client_id, client_secret, Grants_type=authorized_code cũng như 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à phần tóm tắt cơ bản. Một ví dụ chính thức bao gồm nhiều chính sách khác về việc tạo URL, thực hiện chuyển đổi và thực hiện các nhiệm vụ khác. Hãy tham khảo mẫu trên GitHub để biết một dự án hoàn chỉnh và đang hoạt động.

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

Đính kèm chính sách VerifyAccessToken (chính sách OAuthV2 có thao tác VerifyAccessToken được chỉ định) vào đầu mọi quy trình truy cập vào một API được bảo vệ để được thực thi bất cứ khi nào có yêu cầu về tài nguyên được bảo vệ. Edge kiểm tra để đảm bảo mỗi yêu cầu đều có 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 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 OAuth 2.0, bạn cần cung cấp mã truy cập hợp lệ. Cần đưa mã thông báo vào tiêu đề Uỷ quyền như sau: Xin lưu ý rằng mã truy cập 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 bài viết Gửi mã truy cập.