GALAXY TECH
Chuyên gia Công nghệ
Thứ hai, 21/07/2014 | 00:00 GMT+7

Giới thiệu về OAuth 2

OAuth 2 là khung ủy quyền cho phép các ứng dụng có quyền truy cập hạn chế vào account user trên dịch vụ HTTP, chẳng hạn như Facebook, GitHub và DigitalOcean. Nó hoạt động bằng cách ủy quyền xác thực user cho dịch vụ lưu trữ account user và ủy quyền cho các ứng dụng của bên thứ ba truy cập vào account user . OAuth 2 cung cấp các stream ủy quyền cho các ứng dụng web và máy tính để bàn cũng như thiết bị di động.

Hướng dẫn thông tin này hướng tới các nhà phát triển ứng dụng và cung cấp tổng quan về role OAuth 2, các loại cấp ủy quyền, các trường hợp sử dụng và quy trình.

Hãy bắt đầu với Role OAuth!

Role OAuth

OAuth xác định bốn role :

  • Chủ sở hữu tài nguyên
  • Khách hàng
  • Server tài nguyên
  • Server ủy quyền

Ta sẽ trình bày chi tiết từng role trong các phần phụ sau.

Chủ sở hữu tài nguyên: User

Chủ sở hữu tài nguyên là user cho phép ứng dụng truy cập vào account của họ. Quyền truy cập của ứng dụng vào account của user bị giới hạn trong “phạm vi” của ủy quyền được cấp (ví dụ: quyền đọc hoặc ghi).

Server tài nguyên / ủy quyền: API

Server tài nguyên lưu trữ các account user được bảo vệ và server ủy quyền xác minh danh tính của user sau đó cấp mã thông báo truy cập cho ứng dụng .

Theo quan điểm của nhà phát triển ứng dụng, API của dịch vụ đáp ứng cả role tài nguyên và server ủy quyền. Ta sẽ đề cập đến cả hai role này được kết hợp, là role Dịch vụ hoặc API .

Khách hàng: Ứng dụng

Máy khách là ứng dụng muốn truy cập vào account của user . Trước khi có thể làm như vậy, nó phải được user ủy quyền và ủy quyền phải được xác thực bởi API.

Luồng giao thức trừu tượng

Đến đây bạn đã có ý tưởng về role OAuth là gì, hãy xem sơ đồ về cách chúng thường tương tác với nhau:

Luồng giao thức trừu tượng

Dưới đây là giải thích chi tiết hơn về các bước trong sơ đồ:

  1. Ứng dụng yêu cầu ủy quyền để truy cập tài nguyên dịch vụ từ user
  2. Nếu user cho phép yêu cầu, ứng dụng sẽ nhận được một khoản cấp phép
  3. Ứng dụng yêu cầu mã thông báo truy cập từ server ủy quyền (API) bằng cách trình bày xác thực danh tính của chính nó và cấp ủy quyền
  4. Nếu danh tính ứng dụng được xác thực và cấp ủy quyền hợp lệ, server ủy quyền (API) sẽ cấp mã thông báo truy cập cho ứng dụng. Việc ủy quyền đã hoàn tất.
  5. Ứng dụng yêu cầu tài nguyên từ server tài nguyên (API) và xuất trình mã thông báo truy cập để xác thực
  6. Nếu mã thông báo truy cập hợp lệ, server tài nguyên (API) sẽ cung cấp tài nguyên cho ứng dụng

Luồng thực tế của quá trình này sẽ khác nhau tùy thuộc vào loại cấp phép đang sử dụng, nhưng đây là ý tưởng chung. Ta sẽ khám phá các loại trợ cấp khác nhau trong phần sau.

Đăng ký ứng dụng

Trước khi sử dụng OAuth với ứng dụng của bạn , bạn phải đăng ký ứng dụng của bạn với dịch vụ. Điều này được thực hiện thông qua biểu mẫu đăng ký trong phần “nhà phát triển” hoặc “API” trên trang web của dịch vụ, nơi bạn sẽ cung cấp thông tin sau (và có thể là chi tiết về ứng dụng của bạn):

  • Tên ứng dụng
  • Trang web ứng dụng
  • URI chuyển hướng hoặc URL gọi lại

URI chuyển hướng là nơi dịch vụ sẽ chuyển hướng user sau khi họ cho phép (hoặc từ chối) ứng dụng của bạn và do đó phần ứng dụng của bạn sẽ xử lý mã ủy quyền hoặc mã thông báo truy cập.

ID khách hàng và bí mật khách hàng

Sau khi đơn đăng ký của bạn được đăng ký, dịch vụ sẽ cấp “thông tin xác thực khách hàng” dưới dạng mã định danh khách hàng và bí mật khách hàng . ID ứng dụng là một chuỗi hiển thị công khai được API dịch vụ sử dụng để xác định ứng dụng và cũng được sử dụng để tạo URL ủy quyền được hiển thị cho user . Bí mật ứng dụng được sử dụng để xác thực danh tính của ứng dụng với API dịch vụ khi ứng dụng yêu cầu truy cập vào account của user và phải được giữ kín giữa ứng dụng và API.

Cấp phép

Trong Luồng giao thức tóm tắt ở trên, bốn bước đầu tiên bao gồm việc nhận được cấp phép ủy quyền và mã thông báo truy cập. Loại cấp ủy quyền phụ thuộc vào phương thức được ứng dụng sử dụng để yêu cầu ủy quyền và các loại cấp được API hỗ trợ. OAuth 2 xác định bốn loại cấp, mỗi loại đều hữu ích trong các trường hợp khác nhau:

  • Mã ủy quyền : được sử dụng với các Ứng dụng phía server
  • Ngụ ý : được sử dụng với Ứng dụng di động hoặc Ứng dụng web (ứng dụng chạy trên thiết bị của user )
  • Thông tin đăng nhập password của chủ sở hữu tài nguyên : được sử dụng với các Ứng dụng tin cậy , chẳng hạn như các ứng dụng do chính dịch vụ sở hữu
  • Thông tin xác thực ứng dụng khách : được sử dụng với quyền truy cập API ứng dụng

Bây giờ ta sẽ mô tả chi tiết hơn các loại tài trợ, các trường hợp sử dụng và quy trình của chúng, trong các phần sau.

Loại tài trợ: Mã ủy quyền

Loại cấp mã ủy quyền được sử dụng phổ biến nhất vì nó được tối ưu hóa cho các ứng dụng phía server , nơi mã nguồn không bị lộ công khai và có thể duy trì tính bảo mật của Client Secret . Đây là stream dựa trên chuyển hướng, nghĩa là ứng dụng phải có khả năng tương tác với tác nhân user (tức là trình duyệt web của user ) và nhận mã ủy quyền API được định tuyến thông qua tác nhân user .

Bây giờ ta sẽ mô tả stream mã ủy quyền:

Luồng mã ủy quyền

Đầu tiên, user được cung cấp một liên kết mã ủy quyền giống như sau:

/.3415.anews?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

Đây là giải thích về các thành phần liên kết:

  • /.3415.anews : điểm cuối ủy quyền API
  • client_id = client_id : ID khách hàng của ứng dụng (cách API xác định ứng dụng)
  • redirect_uri = CALLBACK_URL : nơi dịch vụ chuyển hướng tác nhân user sau khi mã ủy quyền được cấp
  • response_type = code : chỉ định rằng ứng dụng của bạn đang yêu cầu cấp mã ủy quyền
  • scope = read : chỉ định mức độ truy cập mà ứng dụng đang yêu cầu

Bước 2: Ứng dụng Ủy quyền User

Khi user nhấp vào liên kết, trước tiên họ phải đăng nhập vào dịch vụ để xác thực danh tính của họ (trừ khi họ đã đăng nhập). Sau đó, họ sẽ được dịch vụ nhắc cấp phép hoặc từ chối quyền truy cập của ứng dụng vào account của họ. Đây là một ví dụ cho phép dấu nhắc ứng dụng:

Liên kết mã ủy quyền

Ảnh chụp màn hình cụ thể này là màn hình ủy quyền của DigitalOcean và ta có thể thấy rằng “Ứng dụng Theserverbook” đang yêu cầu ủy quyền cho quyền truy cập “đọc” vào account của “ manicas@digitalocean.com ”.

Bước 3: Đơn đăng ký nhận mã ủy quyền

Nếu user nhấp vào “Ủy quyền ứng dụng”, dịch vụ sẽ chuyển hướng tác nhân user đến URI chuyển hướng ứng dụng, được chỉ định trong quá trình đăng ký ứng dụng cùng với mã ủy quyền . Chuyển hướng sẽ trông giống như thế này (giả sử ứng dụng là “serverbook.com”):

https://serverbook.com/callback?code=AUTHORIZATION_CODE

Bước 4: Yêu cầu ứng dụng Mã truy cập

Ứng dụng yêu cầu mã thông báo truy cập từ API, bằng cách chuyển mã ủy quyền cùng với chi tiết xác thực, bao gồm cả bí mật của ứng dụng client , đến điểm cuối mã thông báo API. Dưới đây là ví dụ về yêu cầu ĐĂNG đến điểm cuối mã thông báo của DigitalOcean:

https://cloud.digitalocean.com/v1/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL

Bước 5: Ứng dụng nhận Mã truy cập

Nếu ủy quyền hợp lệ, API sẽ gửi phản hồi có chứa mã thông báo truy cập (và tùy chọn, mã làm mới) tới ứng dụng. Toàn bộ phản hồi sẽ trông giống như sau:

{"access_token":"ACCESS_TOKEN","token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN","scope":"read","uid":100101,"info":{"name":"Mark E. Mark","email":"mark@thefunkybunch.com"}}

Bây giờ ứng dụng đã được ủy quyền! Nó có thể sử dụng mã thông báo để truy cập vào account của user thông qua API dịch vụ, giới hạn trong phạm vi quyền truy cập, cho đến khi mã thông báo hết hạn hoặc bị thu hồi. Nếu mã thông báo làm mới được phát hành, nó được dùng để yêu cầu mã thông báo truy cập mới nếu mã thông báo ban đầu đã hết hạn.

Loại tài trợ: Không rõ ràng

Loại tài trợ ngầm được sử dụng cho các ứng dụng di động và ứng dụng web (tức là các ứng dụng chạy trong trình duyệt web), nơi tính bảo mật của ứng dụng client không được đảm bảo. Loại cấp ngầm cũng là một quy trình dựa trên chuyển hướng nhưng mã thông báo truy cập được cấp cho tác nhân user để chuyển tiếp đến ứng dụng, do đó, nó có thể được hiển thị cho user và các ứng dụng khác trên thiết bị của user . Ngoài ra, quy trình này không xác thực danh tính của ứng dụng và dựa vào URI chuyển hướng (đã được đăng ký với dịch vụ) để phục vụ mục đích này.

Loại tài trợ ngầm không hỗ trợ mã thông báo làm mới.

Quy trình cấp phép ngầm về cơ bản hoạt động như sau: user được yêu cầu cấp quyền cho ứng dụng, sau đó server ủy quyền chuyển mã truy cập trở lại tác nhân user , mã này sẽ chuyển nó cho ứng dụng. Nếu bạn tò mò về các chi tiết, hãy đọc tiếp.

Dòng chảy ngầm định

Với loại cấp phép ngầm, user được hiển thị với một liên kết ủy quyền, liên kết yêu cầu mã thông báo từ API. Liên kết này trông giống như liên kết mã ủy quyền, ngoại trừ nó đang yêu cầu mã thông báo thay vì mã (lưu ý loại phản hồi “mã thông báo”):

/.3415.anews?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

Bước 2: Ứng dụng Ủy quyền User

Khi user nhấp vào liên kết, trước tiên họ phải đăng nhập vào dịch vụ để xác thực danh tính của họ (trừ khi họ đã đăng nhập). Sau đó, họ sẽ được dịch vụ nhắc cấp phép hoặc từ chối quyền truy cập của ứng dụng vào account của họ. Đây là một ví dụ cho phép dấu nhắc ứng dụng:

Liên kết mã ủy quyền

Ta có thể thấy rằng “Ứng dụng Theserverbook” đang yêu cầu ủy quyền cho quyền truy cập “đọc” vào account “ manicas@digitalocean.com ”.

Bước 3: Tác nhân user nhận Mã truy cập với URI chuyển hướng

Nếu user nhấp vào “Cấp phép ứng dụng”, dịch vụ sẽ chuyển hướng tác nhân user đến URI chuyển hướng ứng dụng và bao gồm một đoạn URI chứa mã thông báo truy cập. Nó sẽ trông giống như thế này:

https://serverbook.com/callback#token=ACCESS_TOKEN

Bước 4: Tác nhân user làm theo URI chuyển hướng

Tác nhân user tuân theo URI chuyển hướng nhưng vẫn giữ lại mã thông báo truy cập.

Bước 5: Ứng dụng gửi tập lệnh extract mã thông báo truy cập

Ứng dụng trả về một trang web chứa tập lệnh có thể extract mã thông báo truy cập từ URI chuyển hướng đầy đủ mà tác nhân user đã giữ lại.

Bước 6: Truy cập mã thông báo được chuyển đến ứng dụng

Tác nhân user thực thi tập lệnh được cung cấp và chuyển mã truy cập được extract cho ứng dụng.

Bây giờ ứng dụng đã được ủy quyền! Nó có thể sử dụng mã thông báo để truy cập vào account của user thông qua API dịch vụ, giới hạn trong phạm vi quyền truy cập, cho đến khi mã thông báo hết hạn hoặc bị thu hồi.

Loại cấp: Thông tin đăng nhập password của chủ sở hữu tài nguyên

Với loại cấp thông tin xác thực password của chủ sở hữu tài nguyên , user cung cấp thông tin đăng nhập dịch vụ của họ (tên user và password ) trực tiếp cho ứng dụng, ứng dụng này sử dụng thông tin đăng nhập để lấy mã thông báo truy cập từ dịch vụ. Loại tài trợ này chỉ nên được bật trên server ủy quyền nếu các stream khác không khả thi. Ngoài ra, nó chỉ nên được sử dụng nếu ứng dụng được user tin cậy (ví dụ: nó thuộc sở hữu của dịch vụ hoặc hệ điều hành máy tính để bàn của user ).

Luồng thông tin đăng nhập password

Sau khi user cung cấp thông tin đăng nhập của họ cho ứng dụng, ứng dụng sẽ yêu cầu mã thông báo truy cập từ server ủy quyền. Yêu cầu ĐĂNG có thể trông giống như sau:

https://oauth.example.com/token?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID

Nếu thông tin đăng nhập của user kiểm tra, server ủy quyền sẽ trả về mã thông báo truy cập cho ứng dụng. Bây giờ ứng dụng đã được ủy quyền!

Lưu ý: DigitalOcean hiện không hỗ trợ loại cấp thông tin xác thực password , vì vậy liên kết trỏ đến server ủy quyền tưởng tượng tại “oauth.example.com”.

Loại tài trợ: Thông tin đăng nhập của khách hàng

Loại cấp thông tin xác thực khách hàng cung cấp cho ứng dụng một cách để truy cập vào account dịch vụ của chính nó. Ví dụ về thời điểm điều này có thể hữu ích bao gồm nếu ứng dụng muốn cập nhật mô tả đã đăng ký hoặc chuyển hướng URI hoặc truy cập dữ liệu khác được lưu trữ trong account dịch vụ của ứng dụng thông qua API.

Luồng thông tin xác thực của khách hàng

Ứng dụng yêu cầu mã thông báo truy cập bằng cách gửi thông tin đăng nhập, ID ứng dụng client và bí mật client , đến server ủy quyền. Một yêu cầu POST mẫu có thể giống như sau:

https://oauth.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

Nếu thông tin đăng nhập ứng dụng được kiểm tra, server ủy quyền sẽ trả về mã thông báo truy cập cho ứng dụng. Bây giờ ứng dụng được phép sử dụng account của chính nó!

Lưu ý: DigitalOcean hiện không hỗ trợ loại cấp thông tin xác thực ứng dụng client , vì vậy liên kết trỏ đến server ủy quyền tưởng tượng tại “oauth.example.com”.

Ví dụ về cách sử dụng mã thông báo truy cập

Khi ứng dụng có mã thông báo truy cập, ứng dụng có thể sử dụng mã thông báo để truy cập account của user thông qua API, giới hạn trong phạm vi quyền truy cập, cho đến khi mã thông báo hết hạn hoặc bị thu hồi.

Đây là một ví dụ về yêu cầu API, sử dụng curl . Lưu ý nó bao gồm mã thông báo truy cập:

curl -X POST -H "Authorization: Bearer ACCESS_TOKEN""https://api.digitalocean.com/v2/$OBJECT"

Giả sử mã thông báo truy cập hợp lệ, API sẽ xử lý yêu cầu theo thông số kỹ thuật API của nó. Nếu mã thông báo truy cập đã hết hạn hoặc không hợp lệ, API sẽ trả về lỗi “invalid_request”.

Làm mới quy trình mã thông báo

Sau khi mã thông báo truy cập hết hạn, việc sử dụng mã này để thực hiện yêu cầu từ API sẽ dẫn đến “Lỗi mã thông báo không hợp lệ”. Đến đây, nếu mã thông báo làm mới được bao gồm khi mã thông báo truy cập ban đầu được phát hành, nó được dùng để yêu cầu mã thông báo truy cập mới từ server ủy quyền.

Đây là một ví dụ về yêu cầu POST, sử dụng mã làm mới để lấy mã thông báo truy cập mới:

https://cloud.digitalocean.com/v1/oauth/token?grant_type=refresh_token&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&refresh_token=REFRESH_TOKEN

Kết luận

Điều đó kết thúc hướng dẫn OAuth 2 này. Đến đây bạn sẽ có một ý tưởng tốt về cách hoạt động của OAuth 2 và khi nào nên sử dụng một quy trình cấp phép cụ thể.

Nếu bạn muốn tìm hiểu thêm về OAuth 2, hãy xem các tài nguyên có giá trị sau:

Tags:

Các tin liên quan