Hiểu về OAuth2 – Hóng hớt scandal Facebook làm lộ dữ liệu người dùng

Gần đây cư dân mạng đang hóng hớt về vụ lùm xùm việc  Facebook làm lộ đến 50.000.000 dữ liệu người dùng. Điều này khiến không ít các bạn lo lắng vì đôi khi chúng ta có khá nhiều thông tin / hành vi nhạy cảm trên Facebook 😀
Và cái hình dưới dây chắc hẳn các bạn cũng không lạ lẫm gì mỗi khi sử dụng App hay WebApp để đăng nhập thông qua Facebook cho “tiện”.

Vậy làm thế nào để các ứng dụng này thu thập được thông tin trên Facebook của chúng ta? Tất cả là tại vì cái giao thức OAuth2, hay còn gọi là một framework dành cho người lười. Chính việc chúng ta thờ ơ với những thông báo uỷ quyền mà Facebook đã cảnh báo, hành vi bấm “Next” vô tội vạ đã đẩy Facebook đến đường cùng như ngày hôm nay =))

Hôm nay, chúng ta sẽ tìm hiểu cho ra ngô ra khoai về cái gọi là “Đăng nhập bằng Facebook/Google” mà chúng ta vẫn thường sử dụng bấy lâu nay. Cũng khuyến cáo trước là bài viết này dành cho anh em laptrinhvien nhé, vì có khá nhiều từ ngữ chuyên ngành nên các bạn “ngoại bang” sẽ cảm thấy hoang mang đấy.

Let’s go

OAuth2 là gì?


OAuth2 là một phiên bản tiếp theo của giao thức OAuth (tuy nhiên nó cũng được gọi là một framework).

Giao thức này cho phép ứng dụng bên thứ 3 được cấp quyền truy cập vào một phần giới hạn tài nguyên thông qua HTTP. Điển hình nhất là ngày nay có rất nhiều ứng dụng cho phép chúng ta đăng nhập thông qua tài khoản Facebook, hay Google. Những ứng dụng này sẽ được phép truy cập một phần tài nguyên của Facebook, Google như avatar, tên, tuổi, năm sinh, giới tính, v.v…

Ở phiên bản 2 này, được kỳ vọng là đơn giản hoá hơn so với phiên bản trước đó để thuận lợi cho việc tương tác giữa các ứng dụng khác nhau.

Chúng được khá nhiều ông lớn như Google, Facebook sử dụng, bên trong nó có gì mà hấp dẫn vậy?

Về Cơ Bản

Roles

OAuth2 định nghĩa 4 roles:

  • Resource Owner: chính là bạn
  • Resource Server: máy chủ lưu trữ thông tin được bảo vệ (ví dụ như Facebook lưu trữ thông tin cá nhân của bạn)
  • Client: Ứng dụng yêu cầu quyền truy cập tài nguyên tới một máy chủ. (Nó có thể là một website, một ứng dụng mobile)
  • Authorization Server: Máy chủ cấp phép một access token cho Client. Token này sẽ được sử dụng để Client yêu cầu lên Resource Server để lấy tài nguyên. Authorization Server thông thường cũng chính là Resource Server. 

Tokens

Token là một chuỗi được sinh ra ngẫu nhiên bởi Authorization Server và được cấp phép khi Client yêu cầu.

Có 2 loại tokens:

  • Access Token: Rất quan trọng, nó như chìa khoá để cho phép ứng dụng bên thứ 3 có quyền truy cập vào dữ liệu người dùng. Token này được gửi bởi Client như một tham số được truyền vào header của mỗi request gửi lên server. Nó có một thời gian sống nhất định, khi hết thời gian sống Client cần yêu cầu lại token từ Authorization Server. 
  • Refresh Token: Token này được cấp cùng với Access Token nhưng lại không giống nhau. Nó không được gửi kèm với header mỗi request. Nó đơn thuẩn chỉ được gửi đến Authorization Server khi mà Access Token đã hết hạn, mục đích là để lấy lại một Access Token mới.

Access token scope

Scope là một tham số dùng để giới hạn quyền của Access Token. Authorization Server sẽ định nghĩa danh sách những scope có sẵn. Client phải gửi những scope nào sử dụng trong suốt quá trình yêu cầu lên Authorization Server.

Tham khảo thêm: http://tools.ietf.org/html/rfc6749#section-3.3

HTTPS

OAuth2 yêu cầu sử dụng HTTPS để giao tiếp giữa Client và Authorization Server vì dữ liệu được truyền giữa chúng là nhạy cảm (các token hoặc có thể là thông tin của bạn). Trong thực tế bạn không bị bắt buộc phải sử dụng HTTPS nếu bạn sử dụng Authorization Server của chính bạn, nhưng bạn phải biết rằng bạn đang mở một lỗ hổng bảo mật nếu như không thực hiện điều này.

Đăng ký như một Client

Vì bạn muốn nhận dữ liệu từ một Resource Server sử dụng OAuth2, bạn phải đăng ký là với Authorization với tư cách là một Client.

Mỗi nhà cung cấp sẽ tự do chọn phương pháp cấp phép theo ý mình, Giao thức OAuth chỉ xác định những tham số được truyền bở Client và những gì mà Authorization Server trả về. Những tham số này có thể khác cách gọi tuỳ thuộc vào nhà cung cấp.

Tham số của một Client:

  • Application Name: tên của ứng dụng
  • Redirect URLs: URLs của client để nhận authorization code và access token.
  • Grant Type(s): Loại uỷ quyền (authorization types) được sử dụng bởi client.
  • Javascript Origin (optional): Máy chủ cho phép yêu cầu resource server thông qua XMLHttpRequest.

Phản hồi của Authorization Server:

  • Client Id: chuổi được sinh ra ngẫu nhiên và duy nhất.
  • Client Secret: khoá bí mật

Authorization grant types: 

OAuth2 định nghĩa 4 loại uỷ quyền phụ thuộc vào vị trí và tính chất của client liên quan đến việc nhận access token.

Authorization Code Grant:

Khi nào sử dụng?

Nó được sử dụng khi mà client là một máy chủ web. Nó cho phép bạn lấy một long-lived access token (một token dài hạn) vì nó có thể được gia hạn thời gian sống bằng một refresh token (tuỳ thuộc vào máy chủ có cho phép hay không).

Ví dụ:

  • Resource Owner: Là Bạn
  • Resource Server: Máy chủ Google
  • Client: Bất kỳ website nào
  • Authorization Server: Máy chủ Google

Kịch bản:

  1. Một website muốn có được thông tin Google profile của bạn.
  2. Bạn được chuyển hướng bởi client tới authorization server (Google)
  3. Nếu bạn cho phép truy cập,  authorization server gửi một authorization code tới client (website) trong phản hổi trả về.
  4. Tiếp đó, authorization code này được trao đổi với một access token giữa client và authorization server.
  5. Website bây giờ có thể sử dụng token này để truy vấn tới resource server ( vẫn là Google) và nhận về thông tin cá nhân của bạn.

Bạn sẽ không thấy được access token, nó được lưu trữ bởi website (trong localStorage hoặc session chẳng hạn). Google cũng sẽ gửi những thông tin khác cùng với access token như token lifetime và refresh token.

More information: RFC 6749 — Authorization Code Grant.

Sơ đồ trình tự: 

Implicit Grant: 

Khi nào sử dụng?

Nó thông thường được sử dụng khi client đang chạy một browser đang sử dụng một scripting language như là Javascript. Loại này thì không cho phép phát hành một refresh token.

Ví dụ: 

  • Resource Owner: Bạn
  • Resource Server: Một server Facebook
  • Client: một website Sử dụng Angular chẳng hạn
  • Authorization Server: Một server Facebook

Kịch bản:

  1. Client (Angular) muốn có thông tin profile Facebook của bạn.
  2. Bạn được chuyển trang bởi trình duyệt tới authorization server (Facebook).
  3. Nếu bạn cho phép truy cập, authorization server chuyển bạn tới trang web với một access token trong đoạn URI (không gửi tới web server).
    Một ví dụ của đoạn URI này như sau: http://example.com/oauthcallback#access_token=MzJmNDc3M2VjMmQzN.
  4. Access token này bây giờ có thể được lấy ra và sử dụng bởi Client (Angular) để truy vấn tới resource server (Facebook). Ví dụ câu truy vấn: https://graph.facebook.com/me?access_token=MzJmNDc3M2VjMmQzN.

Có thể bạn đang tự hỏi làm thế nào để client có thể gọi một Facebook API với javascript mà không bị chặn bởi chính sách Same Origin Policy? Thật may, việc gửi một request cross-domain là có thể được vì Facebook đã uỷ quyền cho nó nhờ một header Access-Control-Allow-Origin xuất hiện trong response trả về.

Tìm hiểu thêm về Cross-Origin Resource Sharing (CORS): https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS#The_HTTP_response_headers.

Chú ý! Loại uỷ quyền nào chỉ nên sử dụng nếu không còn loại uỷ quyền nào khác. Thật vậy, vì nó có độ an toàn kém nhất vì access token là công khai (do đó dễ bị tấn công) trên client

More information: RFC 6749 — Implicit Grant.

Sơ đồ trình tự:

Về các loại “Authorization grant” thì còn khá nhiều nên mình sẽ dành nó ở bài viết sau. Hi vọng bài viết này giúp các bạn hiểu rõ bản chất của việc Facebook thường hỏi quyền các bạn khi đăng ký tài khoản thông qua Facebook.

Lê Xuân Quỳnh – JANETO

30

Bình luận

0933 06 7997
0933 26 7337
tuyensinh@laptrinhvien.io