Làm thế nào để OAuth 2 bảo vệ chống lại những thứ như tấn công lại bằng cách sử dụng Mã thông báo bảo mật?

564

Theo tôi hiểu, chuỗi sự kiện sau xảy ra trong OAuth 2 Site-Ađể truy cập thông tin của Người dùng từ đó Site-B.

Site-Ađăng ký Site-Bvà nhận được Bí mật và ID.
Khi Người dùng bảo Site-Atruy cập Site-B, Người dùng được gửi đến Site-Bnơi họ nói Site-Brằng họ thực sự muốn cấp Site-Aquyền cho thông tin cụ thể.
Site-Bchuyển hướng người dùng quay lại Site-A, cùng với Mã ủy quyền.
Site-Asau đó chuyển Mã ủy quyền đó cùng với Bí mật trở lại để đổi Site-Blấy Mã thông báo bảo mật.
Site-Asau đó thực hiện các yêu cầu Site-Bthay mặt Người dùng bằng cách đóng gói Mã thông báo bảo mật cùng với các yêu cầu.

Làm thế nào để tất cả những điều này hoạt động về mặt bảo mật và mã hóa, ở mức độ cao? Làm thế nào để OAuth 2 bảo vệ chống lại những thứ như tấn công lại bằng cách sử dụng Mã thông báo bảo mật?

oauth-2.0

— William Jones
nguồn

49

oauth2 giải thích đơn giản tại đây: gist.github.com/mziwisky/10079157

— Paolo

4

Đọc thông số kỹ thuật: tools.ietf.org/html/rfc6749 Bạn có thể ngạc nhiên về mức độ dễ hiểu của nó. Nó cũng đúng mà có thể không quá tệ.

— Kris Vandermotten

1

Câu hỏi này và câu trả lời (hiện tại) của nó đều tập trung vào một "loại cấp" cụ thể trong OAuth 2.0 (nghĩa là code) nhưng có các loại cấp khác được định nghĩa trong OAuth 2.0 có liên quan đến các trường hợp sử dụng khác nhau (ví dụ: các loại không liên quan đến người dùng).

— Hans Z.

4

Ồ, tại sao không thay thế "Trang web B" bằng một cái gì đó dễ đọc hơn như "Trang web IdProvider"?

— Yurii

1378

Cách OAuth 2.0 hoạt động trong cuộc sống thực:

Tôi đang lái xe bởi tiệm bánh của Olaf trên đường đi làm thì tôi thấy chiếc bánh rán ngon nhất trong cửa sổ - ý tôi là, thứ đó là thứ nước sô cô la nhỏ giọt. Vì vậy, tôi đã đi vào bên trong và yêu cầu "Tôi phải có cái bánh rán đó!". Ông nói "chắc chắn đó sẽ là 30 đô la."

Vâng tôi biết, $ 30 cho một chiếc bánh rán! Nó phải ngon! Tôi với lấy ví của mình thì đột nhiên tôi nghe thấy đầu bếp hét lên "KHÔNG! Không có bánh rán cho bạn". Tôi đã hỏi tại sao? Ông nói rằng ông chỉ chấp nhận chuyển khoản ngân hàng.

Nghiêm túc? Đúng, anh nghiêm túc. Tôi gần như bỏ đi ngay tại đó, nhưng rồi chiếc bánh rán gọi tôi: "Ăn đi, tôi ngon ...". Tôi là ai mà không tuân theo mệnh lệnh từ một chiếc bánh rán? Tôi nói ok.

Anh ấy đưa cho tôi một ghi chú với tên anh ấy trên đó (đầu bếp, không phải bánh rán): "Hãy nói với họ Olaf gửi cho bạn". Tên của anh ấy đã được ghi chú, vì vậy tôi không biết ý nghĩa của điều đó là gì, nhưng ok.

Tôi lái xe một giờ rưỡi đến ngân hàng của tôi. Tôi đưa bức thư cho người giao dịch; Tôi nói với cô ấy Olaf gửi cho tôi. Cô ấy đưa cho tôi một trong những vẻ ngoài đó, kiểu "Tôi có thể đọc".

Cô ấy đã ghi chú của tôi, hỏi id của tôi, hỏi tôi bao nhiêu tiền là ổn để đưa cho anh ta. Tôi nói với cô ấy 30 đô la. Cô ấy đã viết nguệch ngoạc và đưa cho tôi một ghi chú khác. Cái này có một loạt các số trên đó, tôi đoán đó là cách họ theo dõi các ghi chú.

Lúc đó tôi đang đói. Tôi vội vã rời khỏi đó, một tiếng rưỡi sau tôi đã trở lại, đứng trước Olaf với lời nhắn của tôi được gia hạn. Anh cầm lấy nó, nhìn nó và nói, "Tôi sẽ quay lại".

Tôi nghĩ rằng anh ấy đã nhận được chiếc bánh rán của tôi, nhưng sau 30 phút tôi bắt đầu nghi ngờ. Vì vậy, tôi đã hỏi anh chàng đằng sau quầy "Olaf đâu?". Anh nói "Anh đi lấy tiền". "Ý anh là gì?". "Anh ấy lưu ý đến ngân hàng".

Hả ... vì vậy Olaf đã ghi chú rằng ngân hàng đã đưa cho tôi và quay lại ngân hàng để lấy tiền ra khỏi tài khoản của tôi. Vì anh ta có tờ giấy mà ngân hàng đưa cho tôi, nên ngân hàng biết anh ta là người mà tôi đang nói đến, và vì tôi đã nói chuyện với ngân hàng mà họ biết chỉ đưa cho anh ta 30 đô la.

Phải mất một thời gian dài tôi mới nhận ra điều đó bởi vì khi tôi nhìn lên, Olaf cuối cùng cũng đứng trước mặt tôi đưa cho tôi chiếc bánh rán của tôi. Trước khi tôi rời đi, tôi đã phải hỏi, "Olaf, bạn có luôn bán bánh rán theo cách này không?". "Không, tôi đã từng làm nó khác đi."

Huh. Khi tôi đang trở lại xe, điện thoại của tôi reo lên. Tôi không buồn trả lời, có lẽ công việc của tôi là gọi tôi, ông chủ của tôi là một tên khốn. Bên cạnh đó, tôi bị cuốn vào suy nghĩ về quá trình tôi vừa trải qua.

Ý tôi là nghĩ về điều đó: tôi đã có thể để Olaf lấy $ 30 trong tài khoản ngân hàng của mình mà không phải cung cấp cho anh ta thông tin tài khoản của tôi. Và tôi đã không phải lo lắng rằng anh ta sẽ lấy quá nhiều tiền vì tôi đã nói với ngân hàng rằng anh ta chỉ được phép lấy $ 30. Và ngân hàng biết anh ta là người phù hợp vì anh ta có ghi chú họ đưa cho tôi để gửi cho Olaf.

Ok, chắc chắn tôi thà đưa cho anh ta $ 30 từ túi của tôi. Nhưng bây giờ anh ta có ghi chú đó, tôi chỉ có thể nói với ngân hàng rằng hãy để anh ta lấy $ 30 mỗi tuần, sau đó tôi có thể xuất hiện ở tiệm bánh và tôi không phải đến ngân hàng nữa. Tôi thậm chí có thể đặt bánh rán qua điện thoại nếu tôi muốn.

Tất nhiên tôi sẽ không bao giờ làm điều đó - cái bánh rán đó thật kinh tởm.

Tôi tự hỏi nếu phương pháp này có ứng dụng rộng hơn. Anh ấy đề cập đây là cách tiếp cận thứ hai của anh ấy, tôi có thể gọi nó là Olaf 2.0. Dù sao tôi tốt hơn nên về nhà, tôi phải bắt đầu tìm kiếm một công việc mới. Nhưng không phải trước khi tôi nhận được một trong những quả dâu tây từ nơi mới đó trên khắp thị trấn, tôi cần thứ gì đó để gột rửa hương vị của chiếc bánh rán đó.

— Luis Perez
nguồn

41

Chà, trong thực tế, Olaf sẽ có thể lấy $ 30 từ tài khoản của bạn bất cứ lúc nào anh ta muốn, ngay cả khi bạn không đặt bất kỳ chiếc bánh rán nào. Điều thú vị là đó là mục tiêu chính trong các kịch bản oauth2.0 thực sự :) Đây chắc chắn là một câu trả lời tuyệt vời, nhưng bất cứ ai đang đọc điều này xin vui lòng đi đến ý chính mà Paolo đã đề cập trong bình luận của mình về câu hỏi ( gist.github.com/mziwisky/ 10079157 ). Một bổ sung tốt đọc để làm cho khái niệm tinh thể rõ ràng.

— Samiron

4

Câu trả lời tuyệt vời nhưng có 2 điểm để nâng cao: 1. Như @Samiron đã chỉ ra, Olaf sẽ có thể nhận 30 đô la bất cứ lúc nào anh ta muốn. 2. Trong kịch bản OAuth2.0 thực, Olaf sẽ không thể phục vụ bánh rán trước khi rút tiền ra khỏi ngân hàng. Trong ví dụ này, anh ta có thể giữ tấm séc và chỉ cần đưa cho Luis chiếc bánh rán kiếm được của mình. Vì vậy, nếu chúng ta thay đổi ví dụ để cho phép tôi ủy quyền cho Olaf lấy bột từ một bên thứ ba mà tôi biết, thì sẽ có ý nghĩa hơn khi Olaf sẽ phải lấy bột trước khi anh ta bắt đầu nướng bánh rán (giả sử bánh rán cô đơn Olaf chỉ dành cho mục đích hiển thị!).

— Ticker23

4

ticker23, câu chuyện bánh rán không may đánh bại sự điều chỉnh kỹ thuật của bạn - Tôi đã bị bán trên câu chuyện khi tôi đọc nó. Nó được viết bởi Homer Simpson.

— shevy

4

@Prageeth Olaf luôn mang theo ghi chú đến và từ ngân hàng trong một hộp an toàn bị rò rỉ mực nếu bị giả mạo, sẽ mất nhiều thời gian để khôi phục lại ghi chú. Ngân hàng cũng lấy dấu vân tay của khách hàng trong lần truy cập đầu tiên của họ, nếu Olaf bị mất ngón tay trong một tai nạn nướng bánh thì anh ta sẽ phải yêu cầu Luis thiết lập lại chuyển khoản ngân hàng và ngân hàng sẽ phải xác định Olaf bằng hình xăm Breaking Bread của anh ta vào lần tới .

— Chris

11

Tôi yêu những câu trả lời dễ thương như người tiếp theo, và khi sự dễ thương của chúng giúp câu trả lời dễ tiếp cận hơn thì thật tuyệt vời ... nhưng vào cuối ngày, Stack Overflow nói về việc giáo dục mọi người, và câu chuyện dễ thương này không làm được điều đó. Để hiểu được sự tương tự của bánh rán, bạn phải hiểu cách thức hoạt động của OAuth2, nhưng toàn bộ câu trả lời được cho là phải giải thích chính xác điều đó. Vui lòng xem xét việc chỉnh sửa câu trả lời (trên cùng) này để thực sự giải thích các khái niệm, không chỉ tham chiếu chúng ở cuối ... ngay cả khi điều đó phải trả giá bằng một hoặc hai trò đùa.

— máy

133

Dựa trên những gì tôi đã đọc, đây là cách tất cả hoạt động:

Luồng chung được nêu trong câu hỏi là chính xác. Ở bước 2, Người dùng X được xác thực và cũng cho phép quyền truy cập của Trang A vào thông tin của Người dùng X trên Trang web B. Ở bước 4, trang web chuyển lại Bí mật của mình cho Trang web B, xác thực chính nó, cũng như Mã ủy quyền, cho biết những gì nó đang yêu cầu (mã thông báo truy cập của người dùng X).

Nhìn chung, OAuth 2 thực sự là một mô hình bảo mật rất đơn giản và mã hóa không bao giờ được sử dụng trực tiếp. Thay vào đó, cả Bí mật và Mã thông báo bảo mật về cơ bản là mật khẩu và toàn bộ mọi thứ chỉ được bảo mật bằng bảo mật của kết nối https.

OAuth 2 không có bảo vệ chống lại các cuộc tấn công phát lại của Mã thông báo bảo mật hoặc Bí mật. Thay vào đó, nó hoàn toàn phụ thuộc vào Trang web B chịu trách nhiệm với các mục này và không để chúng thoát ra ngoài và chúng được gửi qua https trong khi quá cảnh (https sẽ bảo vệ các tham số URL).

Mục đích của bước Mã ủy quyền chỉ đơn giản là sự tiện lợi và Mã ủy quyền không đặc biệt nhạy cảm. Nó cung cấp một mã định danh chung cho mã thông báo truy cập của Người dùng X cho Trang web A khi yêu cầu Mã thông báo truy cập của Người dùng X. Chỉ id người dùng của Người dùng X trên Trang web B sẽ không hoạt động, bởi vì có thể có nhiều mã thông báo truy cập nổi bật đang chờ để được trao cho các trang web khác nhau cùng một lúc.

— William Jones
nguồn

28

Bạn đã bỏ qua một chức năng quan trọng của mã ủy quyền. Tại sao không trả lại mã thông báo làm mới (cái mà bạn gọi là Mã thông báo bảo mật) ngay lập tức, thay vì có thêm bước trao đổi mã ủy quyền cho mã này? Bởi vì việc nắm bắt mã thông báo làm mới sẽ cho phép phát lại các cuộc tấn công, trong khi mã ủy quyền chỉ có thể được sử dụng một lần.

— Maurice Naftalin

3

OK, @mauricen, điều đó có ý nghĩa .... Nhưng không thể cuộc tấn công phát lại cũng xảy ra với mã thông báo làm mới, vì đó là những gì kết thúc được thông qua với mỗi yêu cầu?

— Ông Mikkél

15

Mã ủy quyền được truyền qua người dùng, vì vậy (ví dụ) có thể được lưu trữ dưới dạng cookie (xem stackoverflow.com/questions/4065657/ù ). Mã thông báo làm mới chuyển trực tiếp giữa hai trang web, do đó ít bị tổn thương hơn nhiều.

— Maurice Naftalin

Vì tò mò, OAuth có trả lại bất kỳ số nhận dạng duy nhất nào cho chương trình sử dụng không? Ví dụ, tôi hiện đang dựa vào địa chỉ MAC để nhận dạng người dùng, nhưng với điều đó, MAC không đáng tin cậy / dễ dàng giả mạo / v.v. Tôi chỉ có thể loại bỏ cơ chế nhận dạng địa chỉ MAC và truy cập OAuth nếu nó cho phép tôi xác định duy nhất người dùng.

— theGreenCabbage

1

Lưu ý trong sơ đồ này: tools.ietf.org/html/rfc6749#section-4.1 rằng "Bí mật" không được hiển thị, chỉ có Mã định danh khách hàng (ID trong câu hỏi). Tại sao Bí mật quan trọng và tại sao nó không được đưa vào RFC? Ngoài ra trong câu hỏi còn có trạng thái cục bộ được khuyến nghị chuyển qua khi truyền Id khách hàng (A) ban đầu và chuyển hướng trở lại máy khách cùng với mã ủy quyền để bảo vệ chống lại XSSF.

— David Williams

104

OAuth là một giao thức mà ứng dụng 3 bên có thể truy cập dữ liệu của bạn được lưu trữ trong một trang web khác mà không cần tài khoản và mật khẩu của bạn. Để có định nghĩa chính thức hơn, hãy tham khảo Wiki hoặc thông số kỹ thuật.

Dưới đây là bản demo trường hợp sử dụng:

Tôi đăng nhập vào LinkedIn và muốn kết nối một số người bạn trong danh bạ Gmail của mình. LinkedIn hỗ trợ này. Nó sẽ yêu cầu một tài nguyên an toàn (danh sách liên hệ gmail của tôi) từ gmail. Vì vậy, tôi nhấp vào nút này:
Một trang web bật lên và nó hiển thị trang đăng nhập Gmail, khi tôi nhập tài khoản và mật khẩu của mình:
Gmail sau đó hiển thị trang đồng ý nơi tôi nhấp vào "Chấp nhận":
Bây giờ LinkedIn có thể truy cập danh bạ của tôi trong Gmail:

Dưới đây là sơ đồ của ví dụ trên:

Thêm kết nối

Bước 1: LinkedIn yêu cầu mã thông báo từ Máy chủ ủy quyền của Gmail.

Bước 2: Máy chủ ủy quyền Gmail xác thực chủ sở hữu tài nguyên và hiển thị cho người dùng trang đồng ý. (người dùng cần đăng nhập vào Gmail nếu họ chưa đăng nhập)

Bước 3: Người dùng cấp yêu cầu cho LinkedIn truy cập dữ liệu Gmail.

Bước 4: máy chủ ủy quyền Gmail phản hồi lại bằng mã thông báo truy cập.

Bước 5: LinkedIn gọi API Gmail bằng mã thông báo truy cập này.

Bước 6: Máy chủ tài nguyên Gmail trả về danh bạ của bạn nếu mã thông báo truy cập hợp lệ. (Mã thông báo sẽ được xác minh bởi máy chủ tài nguyên Gmail)

Bạn có thể nhận thêm từ chi tiết về OAuth tại đây .

— Owen Cao
nguồn

Tất cả hình ảnh của bạn đã mất tích. Bất kỳ cơ hội nào bạn có thể tải chúng vào stack.imgur?

— ChrisF

1

Làm thế nào điều này có thể đúng? Không phải quá trình này được bắt đầu bởi người dùng ngồi trước máy chủ chứ không phải LinkedIn. Nhưng bạn có điều đó như bước 3. Đây là những gì tôi không nhận được.

— Matt

17

Giải thích đơn giản nhất. Cảm ơn, tôi sẽ không bao giờ mua bánh rán nữa

— OverCoder

Bước 4 linkin trả về với mã thông báo ủy quyền. Điều này phải được cung cấp ở bước thứ 5, nơi chúng tôi sẽ nhận được mã thông báo truy cập và mã thông báo làm mới có thể được sử dụng thêm cho các tài nguyên được bảo vệ.

— amesh

@amesh Cảm ơn, bạn nói đúng, đó là dòng mã ủy quyền, ở đây tôi chỉ nêu một cách đơn giản để thể hiện ý tưởng cơ bản của OAuth 2.

— Owen Cao

24

Hình 1, được nâng lên từ RFC6750 :

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

— 8 bitjunkie
nguồn

13

Đây là cách Oauth 2.0 hoạt động, được giải thích rõ trong bài viết này

— Suraj
nguồn

Bạn có thể mô tả OAUTH2 về việc không sử dụng facebook hoặc bên thứ 3 khác không nhưng nếu bạn sử dụng khóa bí mật và mã thông báo TOTP với ứng dụng điện thoại để bảo mật webapp?

— Al Grant

Facebook là máy chủ Ủy quyền trong ví dụ này phát hành mã thông báo truy cập cho bất kỳ khách hàng nào để họ có thể truy cập API Facebook. Nếu bạn muốn bảo mật API của mình, bạn cần triển khai máy chủ Ủy quyền của riêng mình. Sau đó, bạn quyết định loại Grant bạn muốn sử dụng để nhận mã thông báo truy cập. cho tôi biết chính xác những gì bạn muốn? sẽ giải thích.

— Suraj

Tôi đang xem xét việc thiết lập với bảo mật springboot. Khách hàng (điện thoại) và bí mật trao đổi webapp khi đăng ký - sau đó sử dụng google xác thực để tạo mã dựa trên thời gian / bí mật để nhập trong khi đăng nhập cùng với mật khẩu.

— Al Grant

bình luận cuối cùng của tôi soi sáng cho bạn nữa? Xem hồ sơ của tôi để biết thông tin twitter

— Al Grant

bạn có thể lấy Id khách hàng và bí mật khi đăng ký. Sau đó, điện thoại thực hiện yêu cầu đăng nhập với Id khách hàng vào ứng dụng web của bạn (máy chủ ủy quyền). ứng dụng web xác thực id khách hàng và gửi OTP tới điện thoại. Điện thoại thực hiện một yêu cầu khác với bí mật của khách hàng đối với ứng dụng web để trao đổi OTP với mã thông báo truy cập. điện thoại sử dụng mã thông báo accss này để truy cập các tài nguyên được bảo vệ trên webapp. Tôi nghĩ rằng đây sẽ là luồng Oauth2 cho kịch bản đã cho. Hãy cho tôi biết nếu nó giúp bạn.

— Suraj

10

Đây là một viên ngọc quý:

https://www.digitalocean.com/community/tutorials/an-int sinhtion-to-lauth-2

Tóm tắt rất ngắn gọn:

OAuth xác định bốn vai trò:

Chủ tài nguyên
Khách hàng
Máy chủ tài nguyên
Máy chủ ủy quyền

Bạn (Chủ sở hữu tài nguyên) có một điện thoại di động. Bạn có một số tài khoản email khác nhau, nhưng bạn muốn tất cả tài khoản email của mình trong một ứng dụng, vì vậy bạn không cần phải tiếp tục chuyển đổi. Vì vậy, GMail (Client) của bạn yêu cầu quyền truy cập (thông qua Máy chủ ủy quyền của Yahoo) vào email Yahoo của bạn (Máy chủ tài nguyên) để bạn có thể đọc cả hai email trên ứng dụng GMail của mình.

Lý do OAuth tồn tại là vì GMail không lưu trữ tên người dùng và mật khẩu Yahoo của bạn.

— Tháp chuông
nguồn

8

Câu trả lời khác rất chi tiết và giải quyết phần lớn các câu hỏi được đặt ra bởi OP.

Để giải thích và cụ thể để giải quyết câu hỏi của OP về "Làm thế nào để OAuth 2 bảo vệ chống lại những thứ như tấn công lại bằng Mã thông báo bảo mật?", Có hai biện pháp bảo vệ bổ sung trong các khuyến nghị chính thức để triển khai OAuth 2:

1) Mã thông báo thường sẽ có thời gian hết hạn ngắn ( http://tools.ietf.org/html/rfc6819#section-5.1.5.3 ):

Thời gian hết hạn ngắn cho các mã thông báo là một phương tiện bảo vệ chống lại các mối đe dọa sau:

phát lại...

2) Khi mã thông báo được sử dụng bởi Trang web A, khuyến nghị là nó sẽ được trình bày không phải dưới dạng tham số URL mà trong trường tiêu đề yêu cầu ủy quyền ( http://tools.ietf.org/html/rfc6750 ):

Khách hàng NÊN thực hiện các yêu cầu được xác thực bằng mã thông báo mang theo sử dụng trường tiêu đề yêu cầu "Ủy quyền" với sơ đồ ủy quyền HTTP "Người mang". ...

Phương thức "application / x-www-form-urlencoding" KHÔNG NÊN được sử dụng ngoại trừ trong bối cảnh ứng dụng nơi các trình duyệt tham gia không có quyền truy cập vào trường tiêu đề yêu cầu "Ủy quyền". ...

Tham số truy vấn URI ... được bao gồm trong tài liệu sử dụng hiện tại; sử dụng của nó không được khuyến khích, do sự thiếu hụt bảo mật của nó

— Sẽ
nguồn

3

Đây có lẽ là lời giải thích đơn giản nhất về cách OAuth2 hoạt động cho cả 4 loại cấp, tức là 4 luồng khác nhau trong đó ứng dụng có thể có được mã thông báo truy cập.

Tương tự

Tất cả các luồng cấp có 2 phần:

Nhận mã thông báo truy cập
Sử dụng mã thông báo truy cập

Phần thứ 2 'sử dụng mã thông báo truy cập' giống nhau cho tất cả các luồng

Sự khác biệt

Phần đầu tiên của luồng 'nhận mã thông báo truy cập' cho mỗi loại cấp khác nhau.

Tuy nhiên, nói chung, phần 'nhận mã thông báo truy cập' có thể được tóm tắt bao gồm 5 bước:

Đăng ký trước ứng dụng của bạn (ứng dụng khách) với nhà cung cấp OAuth, ví dụ: Twitter, v.v. để lấy id / bí mật của ứng dụng khách
Tạo nút đăng nhập xã hội với id khách hàng & phạm vi / quyền được yêu cầu trên trang của bạn để khi người dùng nhấp vào được chuyển hướng đến nhà cung cấp OAuth để được xác thực
Nhà cung cấp OAuth yêu cầu người dùng cấp quyền cho ứng dụng (khách hàng) của bạn
Mã nhà cung cấp OAuth cấp mã
Ứng dụng (khách hàng) mua mã thông báo truy cập

Dưới đây là sơ đồ song song so sánh cách mỗi luồng cấp loại khác nhau dựa trên 5 bước.

Sơ đồ này được lấy từ https://blog.oauth.io/int sinhtion-lauth2-stream-diagrams /

Mỗi trường hợp có mức độ khó thực hiện, bảo mật và trường hợp sử dụng khác nhau. Tùy thuộc vào nhu cầu và tình huống của bạn, bạn sẽ phải sử dụng một trong số chúng. Dùng loại nào?

Thông tin khách hàng : Nếu ứng dụng của bạn chỉ phục vụ một người dùng

Mật khẩu của chủ sở hữu tài nguyên Crendential : Điều này chỉ nên được sử dụng như là phương sách cuối cùng vì người dùng phải trao thông tin đăng nhập của mình cho ứng dụng, điều đó có nghĩa là ứng dụng có thể làm mọi thứ mà người dùng có thể

Mã ủy quyền : Cách tốt nhất để có được ủy quyền của người dùng

Tiềm ẩn : Nếu ứng dụng của bạn là ứng dụng dành cho thiết bị di động hoặc một trang

Có nhiều lời giải thích về sự lựa chọn ở đây: https://blog.oauth.io/choose-oauth2-flow-grant-types-for-app/

— nethsix
nguồn