Giải thích OAuthen 2.0 dễ hiểu nhất

Mở đầu

Tuy rằng hiện tại đã có rất nhiều tài liệu cũng như bài viết giải thích về cơ chế xác thực OAuthen, nhưng đối với những người mới bắt đầu tiếp cận với công nghệ, hoặc hạn chế kiến thức về kĩ thuật, thì những document đó có vẻ hơi khó tiếp cận. Vì vậy bài viết này sẽ cố gắng giải thích một cách đơn giản và dễ hiểu nhất, hướng tới mục tiêu giúp cho cả những người hạn chế kiến thức về kĩ thuật cũng có thể tiếp cận được.

Ok, chúng ta bắt đầu thôi.

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

（1）Đầu tiên, chúng ta có User's Data, là phần dữ liệu của người dùng cần được bảo vệ và chia sẻ cho các ứng dụng liên quan. .

（2）Để quản lý User's Data này, chúng ta có 1 server gọi là Resource Server.

（3）Ở đâu đó có 1 Ứng dụng của Client muốn được sử dụng User's Data này.

（4）Để trao đổi User's Data thì phía Resource Server cần chuẩn bị 1 "cánh cửa" để có thể truyền nhận data. "Cánh cửa" này được gọi là API.

（5）Phía ứng dụng Client sẽ gửi request sử dụng User's Data tới Resource Server.

（6）Phía Resource Server sẽ trao User's Data cho ứng dụng Client.

（7）Tuy nhiên, giả sử, nếu ứng dụng Client là 1 Ứng dụng có ý đồ xấu, hay Ứng dụng độc hại.

（8）Khi ứng dụng độc hại này gửi request lấy User's Data tới Resource Server

（9）Thì Resource Server vẫn cứ trao User's Data cho ứng dụng này.

（10）Nếu cứ theo follow như vậy, thì User's Data sẽ được trao cho cả những ứng dụng độc hại, có ý đồ xấu...

（11）Bởi vậy, sẽ cần 1 cơ chế để bảo vệ "cánh cửa" API.

（12）Cơ chế bảo vệ API tốt nhất là trao trước cho Ứng dụng Client 1 thứ gọi là "Access Token". Access Token này sẽ chỉ ra Ứng dụng nào là thích hợp để được cho phép sử dụng User's Data. (Có thể xem Access Token như 1 tấm vé để đi qua cổng API vậy)

（13）Khi Ứng dụng Client gửi request lấy User's Data thì cùng lúc đó sẽ gửi kèm Access Token của mình.

（14）Phía Resource Server sẽ lấy ra Access Token được gửi kèm trong request.

（15）Và kiểm tra xem ứng dụng có quyền sử dụng User's Data hay không.

（16）Nếu confirm được rằng ứng dụng đó có các quyền cần thiết để sử dụng User's Data thì sẽ trao User's Data cho Ứng dụng đó.

（17）Tuy nhiên, để làm cho cơ chế này hoạt động thì cần thiết phải trao Access Token cho Ứng dụng Client trước đó.

（18）Hệ quả đương nhiên là sẽ cần tới một bên quản lý việc phát hành Access Token.

（19）Bên quản lý phát hành Access Token.

（20）Bên quản lý này sẽ được gọi là Authorization Server (Máy chủ uỷ quyền).

（21）Sau đây sẽ giải thích một cách đơn giản hoạt động của Authorization Server và Ứng dụng Client.

（22）Authorization Server sẽ sinh ra Access Token.

（23）Sau đó sẽ phát hành Access Token cho Ứng dụng Client.

（24）Chúng ta sẽ xem xét lại nội dung từ đầu cho tới bây giờ, với các đối tượng là Authorization Server, Ứng dụng Client, Resource Server.

Note：Thực tế thì có nhiều trường hợp cùng 1 server sẽ kiêm luôn Authorization Server và Resource Server.

（25）Authorization Server sẽ sinh ra Access Token.

（26）Sau đó sẽ phát hành Access Token cho Ứng dụng Client.

（27）Ứng dụng Client, sẽ gửi request sử dụng User's Data kèm theo cả Access Token tới Resource Server.

（28）Resource Server sẽ lấy ra Access Token được gửi kèm trong Request.

（29）Và kiểm tra xem với Access Token này thì Ứng dụng Client có quyền sử dụng User's Data hay không?

（30）Nếu có, Resource Server sẽ trao User's Data cho Ứng dụng Client.

（31）Với follow cho tới thời điểm hiện tại, thì Authorization Server sẽ cứ thế mà tạo Access Token rồi phát hành cho Ứng dụng Client. Nhưng trong thực tế thì, trước khi phát hành Access Token, Authorization Server sẽ lấy xác nhận của User. (User ở đây chính là phía sở hữu User's Data.)

（32）Đầu tiên, Ứng dụng Client sẽ gửi request xin Access Token tới Authorization Server.

（33）Sau đó, Authorization Server sẽ xác nhận với User rằng có thể trao cho Ứng dụng Client các quyền mà Ứng dụng này đã request hay không.

（34）Nếu như phía User đồng ý việc trao quyền vào Access Token thì

（35）Phía Authorization Server sẽ sinh Access Token với các quyền tương ứng.

（36）Rồi phát hành Access Token đó cho Ứng dụng Client.

（37）Để ý tới phần được khoanh màu vàng bên dưới

（38）Phần này thể hiện cho việc Request và Response Access Token

（39）Phần này được người ta tiêu chuẩn hoá thành 『OAuth 2.0』. Cụ thể về 『OAuth 2.0』sẽ được định nghĩa trong document RFC 6749

Đến đây là kết thúc phần giải thích cho OAuthen.

Liên quan tới việc xác định tới User xem có cấp quyền cho Ứng dụng Client hay không (hình 33), mình sẽ giải thích cụ thể ở phần sau. Hy vọng rằng bài viết này sẽ giúp ích cho những người mới bắt đầu tiếp cận tới cơ chế bảo mật API.

Bài viết gốc: 一番分かりやすい OAuth の説明