Giới thiệu OAuth2

1. Mở đầu

Gần đây, khi đăng ký hoặc đăng nhập các website chúng ta thường thấy có thêm các chức năng như đăng nhập thông qua tài khoản Facebook, Google... chức năng này rất thuận tiện. Thực tế, mỗi người trong chúng ta đã từng có hàng vài chục tài khoản ở các website khác nhau đến nỗi phải đặt các tài khoản này giống hệt nhau. OAuth ra đời nhằm giải quyết vấn đề trên và xa hơn nữa, OAuth là một giao thức chứng thực nhờ đó một ứng dụng bên thứ 3 có thể đại diện cho người dùng truy cập vào tài nguyên người dùng nằm trong một dịch vụ nào đó. OAuth có thể là viết tắt của Open với Authentication hoặc Authorization, tức bao gồm cả hai công việc:

• Authentication: xác thực người dùng.
• Authorization: người dùng ủy quyền cho ứng dụng truy cập tài nguyên của họ.

1.1 Lịch sử phát triển OAuth

Chúng ta cùng điểm lại vài nét trong lịch sử phát triển của OAuth: - Năm 2006, Twitter phát triển hệ thống OpenID phục vụ cho đăng nhập các ứng dụng trong hệ thống của Twitter, tuy nhiên hệ thống này yêu cầu người dùng phải cung cấp tên đăng nhập và mật khẩu, đây là một điểm yếu. Cũng chính năm này, các ông lớn trong về mạng xã hội như Facebook, Google, Twitter... đã cùng ngồi với nhau để phác thảo ý tưởng về một hệ thống xác thực mới giúp các ứng dụng bên thứ ba có thể tích hợp.

• Năm 2008, IETF - tổ chức quản lý tiêu chuẩn mạng Internet (tránh nhầm với IEEE tổ chức quản lý tiêu chuẩn trong lĩnh vực điện và điện tử) đã quyết định hỗ trợ tiêu chuẩn OAuth này và bắt đầu cho xây dựng RFC 1.0.
• Năm 2010, IETF phát hành phiên bản chính thức đầu tiên của OAuth 1.0 (RFC 5849). Sau đó, lỗi bảo mật nghiêm trọng được phát hiện với tên gọi Session Fixation xảy ra trên OAuth 1.0, cho phép các hacker lừa ứng dụng bên thứ ba trao quyền truy nhập vào tài khoản và dữ liệu người dùng. Năm 2012, phiên bản OAuth 2.0 ra đời, tuy nhiên vẫn còn những lỗi bảo mật chết người các hacker có thể Hack Facebook thông qua trình duyệt Chrome. Từ đó đến nay chưa có thêm một phiên bản nào khác của OAuth ra đời thêm.

OAuth 2 không chỉ đơn thuần là một giao thức (protocol) mà nó còn là một nền tảng (framework) giúp xây dựng ứng dụng cả ở client và server.

1.2 Lược đồ luồng thực hiện cơ bản trong OAuth 2

Trong bài viết này chúng ta sẽ có một số thuật ngữ, do tiếng Việt khá khó để diễn đạt ngắn gọn một thuật ngữ tiếng Anh nên trong bài viết, chúng tôi sẽ sử dụng cả hai dạng thuật ngữ tiếng Việt và thuật ngữ tiếng Anh cho xúc tích.

• Authorization Grant: cấp ủy quyền
• Resource Owner: Người sở hữu tài nguyên hay chính là người dùng (user)
• Authorization server: máy chủ ủy quyền
• Resource server: máy chủ tài nguyên
• Authorization code: mã ủy quyền.
• Access token: thẻ truy nhập, giống như thẻ ra vào tòa nhà, khi có thẻ này bạn có thể vào các vùng dữ liệu để sử dụng.
• Refresh token: thẻ yêu cầu cấp mới, khi các thẻ truy nhập hết hạn sẽ dùng thẻ yêu cầu cấp mới để hệ thống máy chủ ủy quyền cấp mới access token.

Chúng ta cùng bắt đầu tìm hiểu kỹ hơn về OAuth 2 thông qua lược đồ luồng thực hiện. OAuth có 4 đối tượng cần chú ý:

• Resource Owner: Chủ sở hữu dữ liệu
• Client: Ứng dụng, website bên thứ 3
• Authorization server: Máy chủ ủy quyền
• Resource server: Máy chủ tài nguyên, dữ liệu

Trong mô hình dưới đây, chúng tôi sử dụng một ví dụ thực tế để các bạn dễ hiểu hơn. AdShare.vn là một hệ thống quảng cáo dựa trên chia sẻ, một khái niệm mới trong quảng cáo. Trong phần đăng nhập, AdShare hỗ trợ sử dụng các dịch vụ của Facebook, Google, Twitter... Người dùng khi đang nhập vào AdShare có thể ủy quyền cho AdShare thực hiện lấy dữ liệu như thông tin người dùng (không có username, password), Facebook hạn chế chỉ cho phép truy cập thông tin như: tên người dùng, ảnh đại diện, ngày sinh.

Do đây là lược đồ cơ bản nên các hành động có thể được tách thành nhiều các hành động con trong thực tế, bạn sẽ được tìm hiểu kỹ hơn ở phần Ủy quyền. Chúng ta cùng sơ lược qua các luồng thực hiện trong lược đồ cơ bản.

1. Người dùng truy cập vào Adshare.vn thì thấy đăng nhập bằng tài khoản Facebook, người dùng click vào adshare.vn sẽ chuyển hướng đến link đăng nhập Facebook và yêu cầu người dùng đăng nhập.
2. Người dùng thực hiện đăng nhập Facebook và Facebook trả về cho người dùng mã ủy quyền.
3. Adshare.vn gửi yêu cầu tạo access token đến Facebook kèm theo mã ủy quyền nhận được ở bước 3.
4. Máy chủ ủy quyền của Facebook kiểm tra mã ủy quyền, nếu ok nó sẽ trả về access token cho Adshare.vn.
5. Adshare.vn muốn lấy dữ liệu từ các API do Facebook cung cấp sẽ gửi request kèm theo access token.
6. Máy chủ tài nguyên của Facebook kiểm tra access token hợp lệ sẽ trả về dữ liệu thuộc sở hữu của người dùng.

Với ví dụ về xác thực người dùng thông qua Facebook thì chỉ dừng lại ở bước 4 là AdShare.vn đã xác thực được người dùng, OAuth còn đi xa hơn nếu nếu Facebook cung cấp các API để lấy post, chat của người dùng thì bước 5 và 6 mới dùng đến. Thông thường máy chủ xác thực và máy chủ dữ liệu cùng là một với các mô hình vừa và nhỏ. Trên đây là mô hình OAuth nói chung, các bước trên có thể chia tách thành nhiều bước nhỏ hơn hoặc thêm bớt tùy thuộc dạng ủy quyền được sử dụng, chúng ta sẽ bàn luận ở các phần sau.

2. Đăng ký ứng dụng

Trước khi sử dụng OAuth do một dịch vụ nào đó cung cấp (ví dụ Facebook, Github, Google...) trong ứng dụng, cần đăng ký ứng dụng với dịch vụ đó. Đăng ký ứng dụng là điền các thông tin vào form đăng ký của dịch vụ, các thông tin này bao gồm:

• Application name: Tên ứng dụng
• Application website: Trang web của ứng dụng
• Redirect URI hay Callback URL: Đường dẫn trỏ về ứng dụng của bạn để nhận kết quả, khi đường dẫn này kích hoạt bạn có thể nhận được các thông tin như mã ủy quyền hoặc access token.

2.1 Client ID và Client Secret

Khi ứng dụng được đăng ký, dịch vụ sẽ sinh ra cặp dữ liệu Client Id và Client Secret cho ứng dụng. Client ID dùng để dịch vụ nhận diện được ứng dụng, Client Secret là một mã bí mật được sử dụng để xác thực ứng dụng với client ID. Trong ví dụ dưới đây, khi Tích hợp xác thực Facebook vào ứng dụng, bạn cần đăng ký ứng dụng của bạn với Facebook, bạn sẽ thấy các thông tin:

• ID ứng dụng: chính là client id
• Khóa ứng dụng: chính là client secret (do là mã bí mật nên nó không hiển thị, bạn muốn copy mã này thì nhấn vào Hiển thị)
• Tên hiển thị: chính là application name.
• Miền ứng dụng là application website.
• Ngoài ra một số dịch vụ khi sử dụng sẽ cần có cả các trang như chính sách riêng tư và điều khoản dịch vụ.

3. Cấp ủy quyền

Trong mô hình cơ bản ở trên, bốn bước đầu tiên là để lấy được mã ủy quyền (authorization code) và thẻ truy nhập (access token). Mã ủy quyền sẽ được sử dụng bởi ứng dụng để thực hiện lấy access token, khi có được access token, ứng dụng có thể lấy được các tài nguyên thuộc về người dùng. Các dạng ủy quyền phụ thuộc vào cách thức ứng dụng yêu cầu xác thực và dạng ủy quyền được hỗ trợ bởi máy chủ ủy quyền. OAuth 2 có bốn dạng ủy quyền là:

• Mã ủy quyền: sử dụng với các ứng dụng phía máy chủ.
• Ủy quyền ngầm định: được sử dụng bởi các ứng dụng điện thoại và ứng dụng web (các ứng dụng chạy trên thiết bị người dùng cần xác thực).
• Ủy quyền bằng thông tin người dùng: sử dụng với các ứng dụng là các thành viên mở rộng của hệ thống trong đó máy chủ ủy quyền và máy chủ tài nguyên là các thành viên.
• Ủy quyền bằng thông tin ứng dụng: sử dụng với các truy nhập API ứng dụng.

3.1 Cấp ủy quyền sử dụng mã ủy quyền

Loại ủy quyền sử dụng 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 máy chủ, nơi mã nguồn không được công khai do đó các thông tin ứng dụng như client id và client secret được quản lý tốt. Để sử dụng được cách thức cấp ủy quyền này, ứng dụng phải có khả năng tương tác với người dùng (ví dụ, ứng dụng phải thiết lập được các giao diện yêu cầu người dùng đăng nhập máy chủ ủy quyền như "nút đăng nhập sử dụng Facebook") và nhận mã ủy quyền từ người dùng thông qua các giao diện. Chúng ta cùng xem xét Lược đồ cấp ủy quyền sử dụng mã ủy quyền như sau:

1) Người dùng truy nhập vào ứng dụng

2) Ứng dụng đưa ra màn hình có nút "đăng nhập bằng Facebook, Google, Twitter"

3) Người dùng đăng nhập máy chủ ủy quyền, tức là đăng nhập vào Facebook, Google, Twitter (người dùng để ý thì các đường link đăng nhập này chính xác là của Facebook, Google hoặc Twitter...).

Bản chất là người dùng gửi đi một request GET có dạng như sau:

https://authorization-server.com/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

Trong đó các thành phần đường link chi tiết như sau:

• https://authorization-server.com/oauth/authorize là API endpoint.
• client_id là client ID của ứng dụng, giúp máy chủ ủy quyền nhận diện được ứng dụng.
• redirect_uri=CALLBACK_URL: đường dẫn máy chủ ủy quyền sẽ chuyển hướng người dùng sau khi kiểm tra.
• response_type=code: xác định kiểu trả về là mã ủy quyền.
• scope=read: xác định mức độ truy nhập của ứng dụng vào tài nguyên.

4) Facebook, Google, Twitter... sau khi kiểm tra sẽ hiển thị các cảnh báo về quyền hạn của ứng dụng.

5) Người dùng xác nhận cấp quyền cho ứng dụng và cũng là thực hiện chạy redirect URI kèm theo mã ủy quyền.

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

6) Ứng dụng đã có mã ủy quyền và có thể thực hiện yêu cầu máy chủ ủy quyền cung cấp access token bằng cách gửi đi client id, client secret và mã ủy quyền ở dạng POST

https://authorization-server.com/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&
grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL

7) Máy chủ ủy quyền kiểm tra client id, client secret, mã ủy quyền (authorization code) nếu không thấy bất thường sẽ gửi trả lại ứng dụng access token. Response này có dạng như sau:

{"access_token":"ACCESS_TOKEN","token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN","scope":"read","uid":100101,"info":{"name":"Allaravel","email":"allaravel.com@gmail.com"}}

Trong response có cả thời gian sống của access token, sau khoảng thời gian đó, ứng dụng phải sử dụng refresh token để lấy access token mới từ máy chủ ủy quyền.

8) Như vậy, người dùng đã được xác thực, các bước tiếp theo từ 9-13, người dùng yêu cầu dữ liệu nào, ứng dụng sẽ sử dụng access token để lấy dữ liệu từ máy chủ tài nguyên.

3.2 Cấp ủy quyền ngầm định

Cấp ủy quyền ngầm định thường sử dụng cho các ứng dụng điện thoại, đặc điểm là các ứng dụng này chỉ sử dụng bởi duy nhất một người là chủ sở hữu của chiếc điện thoại này. Ví dụ, bạn sử dụng điện thoại Android, khi thiết lập ban đầu bạn phải nhập vào tài khoản của Google, do đó tất cả các ứng dụng tích hợp xác thực Google sẽ tự động xác thực bạn luôn mà không cần phải thực hiện lại các bước như ở cấp ủy quyền bằng mã ủy quyền. Refresh token cũng không cần thiết trong cấp ủy quyền ngầm định. Lược đồ cấp ủy quyền ngầm định như sau:

1) Người dùng truy cập ứng dụng

2) Ứng dụng hiển thị đăng nhập máy chủ ủy quyền cũng chính là gửi request đến máy chủ ủy quyền link có dạng như sau:

https://authorization-server.com/oauth/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

3) Người dùng nhập thông tin vào màn hình trên.

4) Máy chủ ủy quyền kiểm tra nếu không có bất thường sẽ chuyển hướng người dùng về redirect URI kèm theo access token.

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

5) Ứng dụng nhận được access token do người dùng nhấn vào link trên.

8) Người dùng được xác thực

9 - 13) Tiếp theo cũng giống cấp ủy quyền bằng mã ủy quyền, ứng dụng sử dụng access token để lấy dữ liệu do người dùng ủy quyền thực hiện.

3.3 Cấp ủy quyền bằng thông tin người dùng

Người dùng cung cấp thông tin bao gồm username và password trực tiếp cho ứng dụng, khi đó ứng dụng sẽ dùng thông tin này yêu cầu máy chủ ủy quyền cấp access token. Loại ủy quyền này chỉ sử dụng khi các ứng dụng được người dùng tin tưởng hay ứng dụng là một thành phần trong hệ thống lớn trong đó máy chủ ủy quyền, máy chủ tài nguyên cũng là thành phần trong hệ thống đó.

Ví dụ, khi Facebook ra mắt một ứng dụng web A mới, ứng dụng A này là một thành phần của Facebook, do đó người dùng tin tưởng Facebook thì cũng tin tưởng ứng dụng A, do vậy người dùng có thể đăng nhập bằng username, password của Facebook vào ứng dụng A. Ứng dụng A sẽ sử dụng thông tin người dùng (username, password) yêu cầu Facebook cấp access token, request này dạng POST và URL có dạng như sau:

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

Máy chủ ủy quyền sẽ kiểm tra thông tin người dùng cùng với client id của ứng dụng, nếu không có vấn đề gì, nó sẽ cung cấp cho ứng dụng A access token. Như vậy ứng dụng A sẽ có quyền truy xuất tài nguyên trên máy chủ tài nguyên. Các dịch vụ lớn như Facebook, Google, Twitter không bao giờ cung cấp kiểu ủy quyền bằng thông tin người dùng cho các ứng dụng ngoài hệ thống của họ do nếu cung cấp, các ứng dụng ngoài có thể lấy ghi nhận lại thông tin tài khoản người dùng và rất dễ dẫn đến các tình huống như lộ thông tin tài khoản, sử dụng thông tin này khai thác dữ liệu ngoài mục đích...

3.4 Cấp ủy quyền bằng thông tin ứng dụng

Trường hợp này thường dùng khi ứng dụng cần truy nhập tài nguyên hoặc gọi các phương thức từ máy chủ tài nguyên, các tài nguyên này không phụ thuộc vào người dùng xác định (tài nguyên dùng chung).

Ứng dụng yêu cầu access token bằng cách gửi đi các thông tin bí mật gồm client id và client secret đến máy chủ ủy quyền. Thực tế là ứng dụng khách gửi request dạng POST với đường link có kiểu cách như sau:

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

Khi đó, máy chủ ủy quyền kiểm tra thông tin bí mật của ứng dụng nếu đúng nó sẽ gửi trả access token. Lúc này ứng dụng được cấp quyền để truy cập các tài nguyên. ### 3.5 Nên sử dụng loại cấp ủy quyền nào?

Các bạn có thể đã thấy rối khi chúng ta có đến 4 loại ủy quyền khác nhau, tuy nhiên đừng quá lo, với sơ đồ lựa chọn loại ủy quyền trong OAuth 2 dưới đây, sẽ giúp bạn lựa chọn chính xác loại ủy quyền mà bạn cần sử dụng hoặc tự xây dựng một hệ thống khi sử dụng OAuth 2.

4. Các hoạt động khác trong OAuth

4.1 Sử dụng Access Token để lấy dữ liệu

Khi ứng dụng đã nhận được access token, ứng dụng có thể truy cập tài nguyên của máy chủ tài nguyên thông qua các yêu cầu dạng POST. Các cách lấy các tài nguyên này thường được đưa vào trong các tài liệu hướng dẫn sử dụng API của bên cung cấp dịch vụ. Yêu cầu này có dạng như sau:

https://resource-server.com/api/OBJECT

Khi gửi các yêu cầu này, ứng dụng cũng cần thêm thông tin và request header như:

Accept: application/json
Authorization: Bearer ACCESS_TOKEN

Ở đây ACCESS_TOKEN chính là thẻ truy nhập mà ứng dụng nhận được. Nếu access token này chưa hết hạn và được chấp nhận, máy chủ tài nguyên sẽ trả dữ liệu về cho ứng dụng, nếu hết hạn một lỗi "invalid request" sẽ được trả về.

4.2 Yêu cầu gửi access token mới

Access token có thời gian sống nhất định, sau một khoảng thời gian nó sẽ hết hạn, khi đó ứng dụng muốn lấy dữ liệu phải thực hiện yêu cầu access token mới. Ứng dụng phải gửi một yêu cầu đến máy chủ ủy quyền với thông tin kèm theo là refresh token ở dạng POST như sau:

https://authorization-server.com/oauth/token?grant_type=refresh_token&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&refresh_token=REFRESH_TOKEN

Khi đó, máy chủ sẽ trả về cho ứng dụng access token mới, ứng dụng tiếp tục sử dụng access token mới này để lấy dữ liệu trên máy chủ tài nguyên.

5. Dùng OAuth 2 có an toàn không

Nhiều người dùng có câu hỏi OAuth 2 có an toàn không? Chuyện gì xảy ra khi người dùng đăng nhập bằng nick Facebook, Google? câu trả lời là rất an toàn. Chúng ta khi đăng nhập ứng dụng bằng tài khoản Facebook, Google... nhưng ứng dụng không hề biết các thông tin tên đăng nhập và mật khẩu này. Trừ khi dịch vụ đó sử dụng cấp quyền bằng thông tin người dùng, nhưng đã nói ở trên, không bao giờ các dịch vụ này cấp quyền bằng thông tin người dùng cho ứng dụng ngoài hệ thống của họ. Nếu bạn để ý kỹ, đường dẫn khi click vào "Đăng nhập bằng Facebook" chính là đường dẫn đăng nhập Facebook, như hình dưới đây. Do đó bạn hoàn toàn tin tưởng đây là mình đăng nhập Facebook chứ không phải là ứng dụng kia xây dựng form đăng nhập giống Facebook.

https://www.facebook.com/login.php?skip_api_login=1&api_key=1858920067683373&signed_next=1&next=https%3A%2F%2Fwww.facebook.com%2Fv2.8%2Fdialog%2Foauth%3Fredirect_uri%3Dhttp%253A%252F%252Fadshare.vn%252Fauth%252Ffacebook%252Fcallback%26state%3Ds0q22lxt9YQr2zsN72QRJoy83fZPm3DehP1f5rOm%26scope%3Demail%26response_type%3Dcode%26client_id%3D1858920067683373%26ret%3Dlogin%26logger_id%3D12c6bf4a-4b5c-8c2e-c9bc-afc202a1a846&cancel_url=http%3A%2F%2Fadshare.vn%2Fauth%2Ffacebook%2Fcallback%3Ferror%3Daccess_denied%26error_code%3D200%26error_description%3DPermissions%2Berror%26error_reason%3Duser_denied%26state%3Ds0q22lxt9YQr2zsN72QRJoy83fZPm3DehP1f5rOm%23_%3D_&display=page&locale=vi_VN&logger_id=12c6bf4a-4b5c-8c2e-c9bc-afc202a1a846

6. Lời kết

Qua bài viết chúng ta đã có những kiến thức tổng quan nhất về OAuth 2, bài viết có khá nhiều thuật ngữ, chúng tôi cũng cố gắng đưa ra các ví dụ thực tế giúp bạn có thể hiểu dễ dàng hơn các khái niệm trong OAuth 2. Bài viết tổng hợp từ nhiều nguồn và hiểu biết riêng của tác giả, rất mong nhận được ý kiến đóng góp của bạn đọc, các bạn có thể bình luận trong phần Comment ở dưới đây. Bài viết này là nền tảng cho các bài viết về xây dựng hệ thống API trong các ứng dụng sử dụng Laravel. Khi đi vào các ứng dụng thực tế, các bạn sẽ có điều kiện hiểu sâu hơn các thuật ngữ, khái niệm và cách thức sử dụng OAuth 2. Hãy đăng ký nhận bài viết mới, các bạn sẽ nhận được những bài viết mới nhất về OAuth 2 khi chúng tôi phát hành.

---

CÁC BÀI VIẾT KHÁC