Bạn đang xem tài liệu về Apigee Edge.
Chuyển đến tài liệu về
Apigee X. thông tin
Trang chủ OAuth: Xem trang chủ OAuth để biết hướng dẫn tổng quan về OAuth mà chúng tôi cung cấp.
Chủ đề này cung cấp thông tin tổng quan cơ bản về OAuth 2.0 trên Apigee Edge.
OAuth 2.0 là gì?
Có nhiều sách, blog và trang web dành cho OAuth 2.0. Bạn nên bắt đầu bằng cách xem lại thông số kỹ thuật của IETF OAuth 2.0. Dưới đây là định nghĩa của OAuth 2.0 lấy từ chính thông số kỹ thuật của OAuth 2.0 IETF:
"Khung uỷ quyền OAuth 2.0 cho phép ứng dụng bên thứ ba có quyền truy cập hạn chế vào dịch vụ HTTP thay mặt cho chủ sở hữu tài nguyên bằng cách tổ chức hoạt động tương tác phê duyệt giữa chủ sở hữu tài nguyên và dịch vụ HTTP, hoặc bằng cách cho phép ứng dụng bên thứ ba tự lấy quyền truy cập".
Điều chính bạn cần biết là OAuth 2.0 cung cấp cho ứng dụng quyền truy cập hạn chế vào tài nguyên được bảo vệ của người dùng (như tài khoản ngân hàng hoặc bất kỳ thông tin nhạy cảm nào khác mà người dùng có thể muốn truy cập từ ứng dụng) mà không cần người dùng tiết lộ thông tin đăng nhập của họ vào ứng dụng.
Quy trình OAuth 2.0
Dưới đây là quy trình chung cho khung bảo mật OAuth 2.0. Chúng ta sẽ thảo luận chi tiết hơn về quy trình này trong chủ đề này, bắt đầu từ sơ đồ minh hoạ nhiều về cách hoạt động của OAuth 2.0. Nếu bạn chưa quen với các thuật ngữ trong sơ đồ này, hãy đọc phần giới thiệu nhanh.
Các thuật ngữ bạn cần biết
- Ứng dụng: Còn được gọi là "ứng dụng". Đó có thể là một ứng dụng chạy trên thiết bị di động hoặc ứng dụng web truyền thống. Ứng dụng đó thay mặt chủ sở hữu tài nguyên gửi yêu cầu đến máy chủ tài nguyên về các thành phần được bảo vệ. Chủ sở hữu tài nguyên phải cấp cho ứng dụng quyền truy cập vào tài nguyên được bảo vệ.
- Chủ sở hữu tài nguyên: Còn được gọi là "người dùng cuối". Thường thì đây là người (hoặc pháp nhân khác) có khả năng cấp quyền truy cập vào một tài nguyên được bảo vệ. Ví dụ: nếu một ứng dụng cần sử dụng dữ liệu từ một trong những trang web mạng xã hội của bạn, thì bạn chính là chủ sở hữu tài nguyên – người duy nhất có thể cấp cho ứng dụng quyền truy cập vào dữ liệu của bạn.
- Máy chủ tài nguyên: Hãy coi máy chủ tài nguyên là một dịch vụ như Facebook, Google hoặc Twitter; hoặc một dịch vụ nhân sự trên mạng nội bộ của bạn; hoặc một dịch vụ của đối tác trên mạng bổ sung B2B. Apigee Edge là một máy chủ tài nguyên bất cứ khi nào cần xác thực mã thông báo OAuth để xử lý các yêu cầu API. Máy chủ tài nguyên cần có loại uỷ quyền nào đó trước khi phân phát các tài nguyên được bảo vệ cho ứng dụng.
- Máy chủ uỷ quyền: Máy chủ uỷ quyền được triển khai theo thông số kỹ thuật của OAuth 2.0, đồng thời chịu trách nhiệm xác thực các lượt cấp quyền và cấp mã truy cập để cho phép ứng dụng truy cập vào dữ liệu của người dùng trên máy chủ tài nguyên. Bạn có thể định cấu hình "điểm cuối mã thông báo" trên Apigee Edge. Trong trường hợp đó, Edge sẽ đảm nhận vai trò của máy chủ uỷ quyền.
- Cấp quyền truy cập: Cấp cho ứng dụng quyền truy xuất mã truy cập thay mặt cho người dùng cuối. OAuth 2.0 xác định 4 "loại cấp" cụ thể. Xem phần "Các loại cấp quyền truy cập OAuth 2.0 là gì" bên dưới.
- Mã truy cập: Một chuỗi ký tự dài đóng vai trò là thông tin xác thực dùng để truy cập vào các tài nguyên được bảo vệ. Hãy xem thêm phần "Mã truy cập là gì?" bên dưới.
- Tài nguyên được bảo vệ: Dữ liệu do chủ sở hữu tài nguyên sở hữu. Ví dụ: danh bạ, thông tin tài khoản hoặc dữ liệu nhạy cảm khác của người dùng.
Vị trí phù hợp của Apigee Edge
Bạn có thể bảo vệ bất kỳ API nào được xử lý qua máy chủ proxy qua Apigee Edge bằng OAuth 2.0. Edge bao gồm việc triển khai máy chủ uỷ quyền, và do đó, có thể tạo và xác thực mã truy cập. Các nhà phát triển bắt đầu bằng cách đăng ký ứng dụng của họ thông qua Apigee Edge. Các ứng dụng đã đăng ký có thể yêu cầu mã truy cập thông qua một trong bốn lượt tương tác cấp quyền.
Apigee cung cấp một chính sách OAuthV2 đa chiều giúp triển khai thông tin chi tiết của từng loại tài khoản cấp, giúp việc thiết lập OAuth trên Apigee Edge tương đối dễ dàng. Ví dụ: bạn có thể định cấu hình một chính sách nhận yêu cầu cấp mã truy cập, đánh giá tất cả thông tin xác thực bắt buộc và trả về mã truy cập nếu thông tin xác thực hợp lệ.
Xin lưu ý rằng mọi máy chủ tài nguyên mà lệnh gọi proxy API bảo mật của bạn phải được bảo vệ sau tường lửa (nghĩa là không được truy cập vào tài nguyên bằng bất kỳ phương tiện nào ngoài proxy API hoặc một API khác được bảo mật tốt).
Các loại cấp quyền truy cập OAuth 2.0 là gì?
Hãy coi các loại tài trợ là các đường dẫn hoặc hoạt động tương tác khác nhau mà một ứng dụng có thể thực hiện để nhận được mã truy cập. Mỗi loại tài trợ dành cho một hoặc nhiều trường hợp sử dụng và bạn cần chọn(các) loại tài trợ để sử dụng dựa trên nhu cầu của riêng mình. Nhìn chung, mỗi loại hình tài trợ đều có ưu điểm và nhược điểm riêng, do đó bạn cần phải cân nhắc giữa ưu điểm và nhược điểm của các trường hợp sử dụng trong hoạt động kinh doanh của mình. Một yếu tố quan trọng cần cân nhắc là "độ tin cậy" của những ứng dụng sẽ truy cập vào dữ liệu của bạn. Nhìn chung, các ứng dụng bên thứ ba sẽ không đáng tin cậy bằng các ứng dụng được phát triển và sử dụng trong doanh nghiệp.
Apigee Edge hỗ trợ 4 loại tài trợ OAuth 2.0 chính:
- mã uỷ quyền – Được xem là loại cấp quyền an toàn nhất. Trước khi máy chủ uỷ quyền gửi mã truy cập, trước tiên, ứng dụng phải nhận được mã uỷ quyền từ máy chủ tài nguyên. Bạn sẽ thấy quy trình này bất cứ khi nào ứng dụng của bạn mở một trình duyệt để truy cập vào trang đăng nhập của máy chủ tài nguyên và mời bạn đăng nhập vào tài khoản thực của mình (ví dụ: Facebook hoặc Twitter).
Nếu bạn đăng nhập thành công, ứng dụng sẽ nhận được một mã uỷ quyền mà ứng dụng có thể dùng để thương lượng mã truy cập với máy chủ uỷ quyền. Thông thường, loại cấp quyền này được dùng khi ứng dụng nằm trên máy chủ thay vì trên ứng dụng. Loại cấp quyền này được coi là có độ bảo mật cao vì ứng dụng khách không bao giờ xử lý hoặc xem tên người dùng hay mật khẩu của người dùng đối với máy chủ tài nguyên (ví dụ: ứng dụng không bao giờ thấy hoặc xử lý thông tin đăng nhập Twitter của bạn). Quy trình loại tài trợ này còn được gọi là OAuth "ba chân".
- ngầm ẩn – Được xem là phiên bản đơn giản của mã uỷ quyền. Thông thường, loại cấp quyền này được dùng khi ứng dụng nằm trên ứng dụng. Ví dụ: mã của ứng dụng được triển khai trong trình duyệt bằng JavaScript hoặc ngôn ngữ tập lệnh khác (thay vì nằm và chạy trên một máy chủ web riêng). Trong quy trình loại cấp quyền này, máy chủ uỷ quyền trực tiếp trả về mã truy cập khi người dùng đã được xác thực, thay vì cấp mã uỷ quyền trước. Các cấp dữ liệu ngầm ẩn có thể cải thiện khả năng phản hồi của ứng dụng trong một số trường hợp, nhưng bạn cần cân nhắc ưu điểm này với các hệ quả về bảo mật có thể xảy ra như mô tả trong thông số kỹ thuật của IETF.
- thông tin xác thực mật khẩu của chủ sở hữu tài nguyên – Trong quy trình này, ứng dụng sẽ được cấp một mã truy cập khi tên người dùng/mật khẩu của người dùng đã được máy chủ uỷ quyền xác thực. Bạn nên sử dụng quy trình này cho các ứng dụng có độ tin cậy cao. Giả sử quy trình xác thực cơ bản này có ưu điểm là người dùng chỉ hiển thị tên người dùng/mật khẩu của họ một lần duy nhất. Kể từ đó, mã truy cập sẽ được sử dụng.
- thông tin xác thực của ứng dụng khách – Cân nhắc sử dụng trong các tình huống mà ứng dụng khách đang tự hành động. Tức là ứng dụng khách cũng là chủ sở hữu tài nguyên. Loại quyền này thường được dùng khi ứng dụng cần truy cập vào dịch vụ lưu trữ dữ liệu phụ trợ, chẳng hạn. Ứng dụng cần dùng dịch vụ để thực hiện công việc của nó và nếu không dịch vụ sẽ được làm mờ đối với người dùng cuối. Với loại cấp quyền này, một ứng dụng có thể nhận được mã truy cập bằng cách trình bày mã ứng dụng khách và khoá bí mật của ứng dụng cho máy chủ uỷ quyền. Bạn không cần thực hiện thêm bước nào nữa. Edge cung cấp một giải pháp thông tin xác thực ứng dụng có sẵn dễ triển khai cho mọi proxy API.
Mã truy cập là gì?
Mã truy cập là một chuỗi ký tự dài đóng vai trò là thông tin xác thực dùng để truy cập vào các tài nguyên được bảo vệ. Mã thông báo tài nguyên (còn gọi là mã thông báo truy cập) được chuyển trong tiêu đề Uỷ quyền như sau:
$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \ http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282
Máy chủ tài nguyên hiểu rằng mã truy cập "đại diện" cho các thông tin đăng nhập như tên người dùng và mật khẩu. Ngoài ra, mã truy cập có thể được cấp một số hạn chế để chẳng hạn như ứng dụng có thể đọc nhưng không thể ghi hoặc xoá dữ liệu trên máy chủ tài nguyên. Xin lưu ý rằng mã truy cập có thể bị thu hồi trong trường hợp ứng dụng bị xâm phạm. Trong trường hợp này, bạn sẽ phải có mã truy cập mới để tiếp tục dùng ứng dụng. Tuy nhiên, bạn sẽ không phải thay đổi tên người dùng hoặc mật khẩu trên máy chủ tài nguyên được bảo vệ (ví dụ: Facebook hoặc Twitter).
Mã truy cập thường có thời hạn (vì lý do bảo mật). Một số loại cấp cho phép máy chủ uỷ quyền cấp mã làm mới. Mã này cho phép ứng dụng tìm nạp mã truy cập mới khi mã cũ hết hạn. Để biết thêm thông tin chi tiết về mã truy cập và làm mới, hãy tham khảo thông số kỹ thuật của IETF OAuth 2.0.
Quyền truy cập bị giới hạn thông qua phạm vi
Thông qua cơ chế phạm vi, OAuth 2.0 có thể cấp cho một ứng dụng quyền truy cập có giới hạn vào các tài nguyên được bảo vệ. Ví dụ: một ứng dụng có thể chỉ có quyền truy cập vào một số tài nguyên, có thể cập nhật tài nguyên hoặc chỉ được cấp quyền chỉ có thể đọc. Trong quy trình gọi là luồng OAuth "3 bên", người dùng thường chỉ định cấp truy cập thông qua một trang yêu cầu đồng ý (ví dụ: một trang web mà người dùng chọn phạm vi bằng hộp đánh dấu cho cơ chế khác).
Đăng ký ứng dụng
Tất cả ứng dụng (ứng dụng) phải đăng ký với máy chủ uỷ quyền OAuth 2.0 mà họ định yêu cầu mã truy cập từ đó. Khi đăng ký ứng dụng, bạn sẽ nhận lại được một bộ khoá. Một khoá là khoá công khai được gọi là giá trị nhận dạng ứng dụng và một khoá bí mật có tên là khoá bí mật của ứng dụng. Nếu không có những khoá này, ứng dụng không thể gửi yêu cầu cung cấp mã uỷ quyền hoặc mã truy cập đến máy chủ uỷ quyền. Xin lưu ý rằng mặc dù thông số kỹ thuật OAuth của IETF gọi những mã ứng dụng khách và mật khẩu ứng dụng khách của các khoá này, nhưng giao diện người dùng Apigee Edge sẽ gọi những khoá này là Mã nhận dạng người tiêu dùng và Bí mật người tiêu dùng. Các giá trị này tương đương với nhau.
Tóm tắt các trường hợp sử dụng OAuth 2.0
Quy trình loại cấp quyền truy cập OAuth 2.0 mà bạn chọn triển khai phụ thuộc vào trường hợp sử dụng cụ thể của bạn, vì một số loại cấp có tính bảo mật hơn so với các loại khác. Việc lựa chọn loại cấp quyền phụ thuộc vào độ tin cậy của ứng dụng khách, nên bạn cần phải xem xét thật cẩn thận, theo mô tả trong bảng sau:
| Trường hợp sử dụng | Độ tin cậy | Các loại cấp quyền ủy quyền OAuth 2.0 được đề xuất | Nội dung mô tả |
|---|---|---|---|
| B2B (mạng riêng), mạng nội bộ, khác |
Các ứng dụng có độ tin cậy cao, do nhà phát triển nội bộ hoặc nhà phát triển có mối quan hệ kinh doanh đáng tin cậy với nhà cung cấp API viết. Những ứng dụng cần tự truy cập vào tài nguyên. |
|
|
| Trang web, cổng nội bộ |
Ứng dụng đáng tin cậy do nhà phát triển nội bộ hoặc nhà phát triển bên thứ ba đáng tin cậy viết. Một ví dụ điển hình là đăng nhập vào trang web về nhân sự của công ty để lựa chọn bảo hiểm, gửi bài đánh giá hoặc thay đổi thông tin cá nhân. |
|
|
| Ứng dụng được phát hành công khai | Ứng dụng không đáng tin cậy là ứng dụng do những nhà phát triển bên thứ ba không có mối quan hệ kinh doanh đáng tin cậy với nhà cung cấp API viết. Ví dụ: những nhà phát triển đăng ký chương trình API công khai thường không đáng tin cậy. |
|
|
| B2C | Có một người dùng cuối cá nhân (người dùng thiết bị di động) và thông tin đăng nhập của người dùng được lưu trữ trên thiết bị di động. |
|
|
Bảo mật OAuth 2.0 so với khoá API
Xác thực khoá API yêu cầu ứng dụng gửi khoá cho Edge. Khoá này phải là khoá người dùng hợp lệ của một ứng dụng dành cho nhà phát triển Apigee Edge được liên kết với proxy API. Nếu vì lý do nào đó mà bạn cần thu hồi quyền để một ứng dụng khách thực hiện lệnh gọi đến proxy, bạn phải thu hồi khoá người dùng đó. Mọi ứng dụng khách dùng khoá đó cũng sẽ không thể truy cập vào proxy API. Mặt khác, bạn có thể thu hồi mã thông báo OAuth bất cứ lúc nào mà không cần thu hồi các khoá của ứng dụng. Ứng dụng chỉ cần thay mặt người dùng yêu cầu mã thông báo mới và nếu mã được cấp, ứng dụng có thể tiếp tục sử dụng proxy API.
Một điểm khác biệt khác giữa khoá API và mã thông báo là mã thông báo có thể chứa các thuộc tính siêu dữ liệu mà bạn có thể truy xuất và sử dụng sau này. Ví dụ: bạn có thể lưu trữ mã nhận dạng của người dùng thực hiện lệnh gọi API và sử dụng mã đó để tuỳ chỉnh lệnh gọi đến dịch vụ đích phụ trợ.
Để biết thông tin chi tiết về việc xác thực khoá API, hãy xem nội dung Khoá API. Để biết thông tin về cách sử dụng thuộc tính tuỳ chỉnh với mã thông báo OAuth, hãy xem bài viết Tuỳ chỉnh mã thông báo và Mã uỷ quyền.