Giới thiệu về OAuth 2.0

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

Trang chủ OAuth: Xem trang chủ OAuth để biết thông tin tổng quan về hướng dẫn 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 riêng cho OAuth 2.0. Bạn nên bắt đầu bằng cách xem quy cách IETF OAuth 2.0. Dưới đây là định nghĩa về OAuth 2.0 theo chính quy cách OAuth 2.0 IETF:

"Khung uỷ quyền OAuth 2.0 cho phép một ứng dụng bên thứ ba có được quyền truy cập hạn chế vào một dịch vụ HTTP, thay mặt cho chủ sở hữu tài nguyên bằng cách điều phối một 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 có được quyền truy cập thay mặt cho chính ứng dụng đó."

Điều chính mà bạn cần biết là OAuth 2.0 cung cấp cho các ứng dụng một cách để có được quyền truy cập hạn chế vào các tài nguyên được bảo vệ của người dùng (hãy nghĩ đến 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ừ mộ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ọ cho ứng dụng.

Quy trình OAuth 2.0

Sau đâ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 bằng một sơ đồ minh hoạ nhiều thông tin 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ữ được dùng trong sơ đồ này, hãy đọc phần này để biết thông tin giới thiệu nhanh.

Những thuật ngữ bạn nên biết

• Client: 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 một ứng dụng web truyền thống. Ứng dụng này gửi yêu cầu đến máy chủ tài nguyên để lấy các tài sản được bảo vệ thay cho chủ sở hữu tài nguyên. Chủ sở hữu tài nguyên phải cấp cho ứng dụng quyền truy cập vào các 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". Đây thường là người (hoặc thực thể 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 các trang mạng xã hội của bạn, thì bạn 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ụ đối tác trên mạng ngoại bộ B2B của bạn. 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 một số loại uỷ quyền trước khi cung cấp 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 tuân thủ quy cách OAuth 2.0 và chịu trách nhiệm xác thực quyền uỷ quyền cũng như 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 này, Edge sẽ đảm nhận vai trò máy chủ uỷ quyền.
• Uỷ quyền cấp quyền: 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 quyền sử dụng" cụ thể. Hãy xem phần "Các loại quyền sử dụng 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 được dùng để truy cập vào các tài nguyên được bảo vệ. 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 thuộc quyền sở hữu của chủ sở hữu tài nguyên. Ví dụ: danh sách liên hệ, 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ị thế của Apigee Edge

Bạn có thể bảo vệ mọi API được uỷ quyền thông qua Apigee Edge bằng OAuth 2.0. Edge có một chế độ triển khai máy chủ uỷ quyền và do đó, có thể tạo và xác thực mã truy cập. Nhà phát triển bắt đầu bằng cách đăng ký ứng dụng với Apigee Edge. Các ứng dụng đã đăng ký có thể yêu cầu mã truy cập thông qua bất kỳ tương tác nào trong số 4 tương tác loại cấp quyền.

Apigee cung cấp một chính sách OAuthV2 đa khía cạnh, triển khai thông tin chi tiết của từng loại cấp phép, giúp bạn tương đối dễ dàng thiết lập OAuth trên Apigee Edge. Ví dụ: bạn có thể định cấu hình một chính sách nhận yêu cầu về mã truy cập, đánh giá tất cả thông tin đăng nhập bắt buộc và trả về mã truy cập nếu thông tin đăng nhập hợp lệ.

Xin lưu ý rằng mọi máy chủ tài nguyên mà proxy API bảo mật của bạn gọi đều phải nằm sau tường lửa (tức 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 quyền sử dụng OAuth 2.0 là gì?

Hãy coi các loại cấp phép là những đườ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 cấp quyền sẽ giải quyết một hoặc nhiều trường hợp sử dụng và bạn cần chọn(các) loại cấp quyền cần sử dụng dựa trên nhu cầu của riêng mình. Nhìn chung, mỗi loại cấp quyền đều có ưu và nhược điểm, đồng thời bạn cần cân nhắc những điểm đánh đổi dựa trên các trường hợp sử dụng cho doanh nghiệp của mình. Một yếu tố quan trọng cần cân nhắc là "độ tin cậy" của các ứ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 ít đáng tin cậy hơn so với các ứng dụng được phát triển và sử dụng trong một doanh nghiệp.

Apigee Edge hỗ trợ 4 loại quyền sử dụng OAuth 2.0 chính:

• mã uỷ quyền – Được coi là loại cấp phép an toàn nhất. Trước khi máy chủ uỷ quyền cấp mã truy cập, ứng dụng trước tiên phải nhận được mã uỷ quyền từ máy chủ tài nguyên. Bạn đã 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 đến 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 này được dùng khi ứng dụng nằm trên một máy chủ thay vì trên máy khách. Loại cấp quyền này được coi là rất an toàn vì ứng dụng khách không bao giờ xử lý hoặc thấy tên người dùng hoặc mật khẩu của người dùng cho 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). Luồng loại cấp quyền này còn được gọi là OAuth "ba chân".

• implicit – Được coi là phiên bản đơn giản của mã uỷ quyền. Thông thường, loại cấp phép này được dùng khi ứng dụng nằm trên máy khách. Ví dụ: mã của ứng dụng được triển khai trong một trình duyệt bằng JavaScript hoặc một ngôn ngữ kịch bản khác (thay vì nằm và chạy trên một máy chủ web riêng biệt). Trong quy trình loại cấp quyền này, máy chủ uỷ quyền sẽ trả về trực tiếp mã truy cập khi người dùng được xác thực, thay vì trước tiên phát hành mã uỷ quyền. Trong một số trường hợp, việc cấp ngầm có thể cải thiện khả năng phản hồi của ứng dụng, nhưng bạn cần cân nhắc lợi ích này với những tác động có thể xảy ra đối với tính bảo mật như mô tả trong quy cách IETF.
• thông tin đăng nhập mật khẩu của chủ sở hữu tài nguyên – Trong quy trình này, ứng dụng khách sẽ được cấp mã truy cập khi máy chủ uỷ quyền xác thực tên người dùng/mật khẩu của người dùng. Bạn nên sử dụng quy trình này cho các ứng dụng có độ tin cậy cao. Một lợi thế của quy trình này so với quy trình xác thực cơ bản là người dùng chỉ cần cung cấp tên người dùng/mật khẩu một lần. Kể từ đó, mã truy cập sẽ được sử dụng.
• client credentials – Cân nhắc sử dụng cho những trường hợp ứng dụng khách đang hành động thay cho chính ứng dụng đó. Tức là ứng dụng cũng là chủ sở hữu tài nguyên. Loại cấp phép này thường được dùng khi ứng dụng cần truy cập vào một dịch vụ lưu trữ dữ liệu phụ trợ, chẳng hạn như. Ứng dụng cần sử dụng dịch vụ này để thực hiện công việc và dịch vụ này không hiển thị cho người dùng cuối. Với loại cấp phép này, một ứng dụng có thể nhận được mã truy cập bằng cách xuất trình khoá bí mật và mã ứng dụng khách cho máy chủ uỷ quyền. Bạn không cần làm gì thêm. Edge cung cấp một giải pháp thông tin đăng nhập của ứng dụng có sẵn, dễ dàng 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 người mang) được truyề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 "thay thế" cho 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 kèm theo các 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ã thông báo truy cập có thể bị thu hồi nếu, chẳng hạn như, ứng dụng bị xâm nhập. Trong trường hợp này, bạn sẽ cần lấy mã truy cập mới để tiếp tục sử 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).

Thông thường, mã truy cập sẽ hết hạn (vì lý do bảo mật). Một số loại quyền cho phép máy chủ uỷ quyền cấp mã làm mới, nhờ đó, ứng dụng có thể tìm nạp mã truy cập mới khi mã truy cập cũ hết hạn. Để biết thêm thông tin chi tiết về mã truy cập và mã làm mới, hãy tham khảo quy cách IETF OAuth 2.0.

Hạn chế quyền truy cập thông qua các phạm vi

Thông qua cơ chế phạm vi, OAuth 2.0 có thể cấp cho ứ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 các tài nguyên cụ thể, có thể cập nhật tài nguyên hoặc chỉ được cấp quyền truy cập chỉ đọc. Trong các quy trình OAuth "ba chân", người dùng thường chỉ định cấp độ truy cập thông qua một trang đồng ý (ví dụ: một trang web nơi người dùng chọn phạm vi bằng hộp đánh dấu hoặc cơ chế khác).

Đăng ký ứng dụng

Tất cả ứng dụng phải đăng ký với máy chủ uỷ quyền OAuth 2.0 mà chúng dự định yêu cầu mã truy cập. Khi đăng ký một ứng dụng, bạn sẽ nhận được một bộ khoá. Một là khoá công khai có tên là giá trị nhận dạng ứng dụng khách và khoá còn lại là khoá bí mật có tên là khoá bí mật của ứng dụng khách. Nếu không có các khoá này, ứng dụng sẽ không thể đưa ra yêu cầu về mã uỷ quyền hoặc mã thông báo truy cập cho máy chủ uỷ quyền. Xin lưu ý rằng mặc dù quy cách OAuth của IETF gọi các khoá này là mã ứng dụng khách và khoá bí mật của ứng dụng khách, nhưng giao diện người dùng Apigee Edge gọi các khoá này là mã nhận dạng người dùng và khoá bí mật của người dùng. Chúng tương đương nhau.

Tóm tắt các trường hợp sử dụng OAuth 2.0

Loại quy trình cấp quyền 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 quyền an toàn hơn những loại khác. Lựa chọn của bạn về các loại cấp phụ thuộc vào độ tin cậy của ứng dụng khách và đòi hỏi bạn phải cân nhắc rất kỹ, như mô tả trong bảng sau:

Bảo mật khoá API so với OAuth 2.0

Quá trình xác thực khoá API yêu cầu ứng dụng gửi một khoá đến Edge. Khoá này phải là một khoá của người dùng: hợp lệ từ một ứng dụng 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 của một ứng dụng khách để thực hiện các lệnh gọi đến một proxy, thì bạn phải thu hồi khoá của người dùng đó. Mọi ứng dụng khách sử 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 khoá của ứng dụng. Ứng dụng chỉ cần yêu cầu một mã thông báo mới thay cho người dùng và nếu được cấp mã thông báo, ứng dụng có thể tiếp tục sử dụng proxy API.

Một điểm khác biệt nữa giữa khoá API và mã thông báo là mã thông báo có thể bao gồm 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ã nhận dạng đó để tuỳ chỉnh các 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 phần 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 phần Tuỳ chỉnh mã thông báo và mã uỷ quyền.

Tài nguyên được đề xuất

Đọc sách

Xem phần Tìm hiểu về OAuth 2.0.