Giải thích OpenID Connect dễ hiểu nhất

Mở đầu

Tiếp nối với bài Giải thích OAuthen 2.0 dễ hiểu nhất sẽ là bài dịch Giải thích OpenID Connect dễ hiểu nhất.

Link bài viết gốc: https://qiita.com/TakahikoKawasaki/items/498ca08bbfcc341691fe

Bắt đầu giải thích

（１）Giả sử có 1 đoạn hội thoại xàm như sau

「Hello! Anh Hoàng đây em.」

（２）「Uầy, thật ko đó? Chứng minh đi」

（３）「Ờ, anh chứ ai, danh thiếp của anh đây」

（４）「Uầy, danh thiếp này thì ai không làm được. 」

（５）Lần này anh Hoàng mang theo 1 danh thiếp mới. 「Hello! Anh Hoàng đây em. Anh có mang theo danh thiếp có cả chữ kí của công ty anh đây.」

（６）「Rồi rồi, để em xem đã.」

（７）Người nhận danh thiếp mang tới công ty có tên trên danh thiếp để hỏi. 「Công ty XXX ơi?」

（８）「Đây! Có chuyện gì?」

（９）「Em có nhận được 1 danh thiếp có chữ kí công ty anh mà không biết thật hay giả. Cho em xin cái [Public key] để check đi anh.

（１０）「Ok của chú đây.」（Gửi Public key）

（１１）Sử dụng Public key nhận được để verify chữ kí trên danh thiếp và confirm được là danh thiếp này đúng do công ty XXX phát hành. 「Ngon rồi, em xác nhận danh thiếp của anh là hàng thật nhé..」

（１２）Đến đây thì chúng ta thấy xuất hiện 1 khái niệm là 『Danh thiếp có chữ kí của nhà phát hành』(ND: Mục đích của câu chuyện xàm ở trên là để dẫn dắt tới khái niệm về 1 thứ dùng để chứng minh danh tính)

（１３）Tương đương với khái niệm 『Danh thiếp có chữ kí của nhà phát hành』ở đây là khái niệm『ID Token』

（１４）Với danh thiếp thì có nhà phát hành thì với ID Token cũng có nhà phát hành ID Token

（１５） Nhà phát hành ID Token được gọi là 『OpenID Provider』

（１６）Sau đây sẽ giải thích một cách đơn giản mối quan hệ giữa ứng dụng client (phía nhận ID Token) và OpenID Provider.

（１７）OpenID Provider tạo ID Token.

（１８）Rồi phát hành ID Token cho ứng dụng client.

（１９）Follow ở trên thì OpenID tự động tạo ID Token rồi phát hành cho ứng dụng client. Nhưng thực tế thì trước khi phát hành ID Token cho client thì OpenID Provider sẽ hỏi tới User xem có phát hành ID Token hay không. Nếu được cho phép thì User sẽ phải cung cấp thông tin xác nhận danh tính. Nói cách khác sẽ tiến hành authenticate User.

（２０）Trước tiên, ứng dụng client sẽ yêu cầu ID Token từ OpenID Provider

（２１）Sau đó, OpenID Provider sẽ hỏi tới User xem có phát hành ID Token hay không. Nếu được User đồng ý phát hành ID Token thì sẽ yêu cầu User đưa ra thông tin chứng thực danh tính, tức là tiến hành Authenticate User.

(Cách thức authenticate User thì có thể bằng User ID + Password hoặc nhiều hình thức khác)

（２２）Nếu nhận được sự đồng ý cấp ID Token từ User, và thực hiện Authenticate User thành công thì,

（２３）OpenID Provider sẽ tạo ID Token

（２４）Rồi phát hành ID Token cho client.

（２５）Chú ý phần khoanh vàng này

（２６）Chỗ này thể hiện cho việc Request và Response ID Token

（２７）Phần này được người ta tiêu chuẩn hoá thành 『OpenID Connect』. Cụ thể về 『OpenID Connect』sẽ được định nghĩa trong document 『OpenID Connect Core 1.0』

（２８）Nhân tiện, follow của OpenID Connect rất giống với follow của phần [Giải thích OAuthen 2.0] ](https://viblo.asia/p/giai-thich-oauthen-20-de-hieu-nhat-4P8566pG5Y3)đúng ko nào?

OAuthen 2.0

OpenID Connect

（２９）Điều đó là hiển nhiên, cả hai luồng xử lý đều tương tự nhau vì OpenID Connect là một phần mở rộng của OAuth 2.0. OAuth 2.0 xác định luồng xử lý để phát hành Access Token, OpenID Connect mở rộng follow đó để phát hành ID Token. Trên website của OpenID cũng nói rõ

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol.

(Identity, Authentication) + OAuthen 2.0 = OpenID Connect

（３０）Trên thì việc để 1 server đảm nhận cả vai trò là OpenID Provider và Authorization server khá là phổ biến.

（３１）Trong trường hợp đó thì phía ứng dụng client có thế cùng lúc request ID Token lẫn Access Token.

（３２）Sau khi nhận request ID Token và Access Token, OpenID Provider kiêm Authorization server sẽ hỏi tới User xem có phát hành ID Token và Access Token cho Client hay không. Nếu được cho phép thì sẽ yêu cầu User cung cấp thông tin xác nhận danh tính.

（３３）Nếu nhận được sự đồng ý cấp ID Token và Access Token từ User, và thực hiện Authenticate User thành công thì,

（３４）OpenID Provider kiêm Authorization server sẽ tạo ID Token và Access Token,

（３５）Rồi phát hành ID Token và Access Token cho ứng dụng client.

（３６）Cuối cùng, rốt cuộc vì sao người ta lại đẻ ra ID Token? Nguyên nhân là vì cách thức này có thể authenticate được User, cũng như đảm bảo được các thông tin thuộc User này không bị giả mạo. Việc này cho phép việc 1 User khi đã được authenticate ở 1 nơi ( 1 OpenID Provider), thì với ID Token đã phát hành cho User đó, có thể đem đi sử dụng ở những nơi khác, và sẽ không cần thực hiện lại việc authenticate User đó nữa.

Giải thích đến đây chấm hết, cảm ơn các bạn đã theo dõi