Nghiên cứu giao thức OAuth và ứng dụng trong xác thực

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN HỒNG NHUNG

NGHIÊN CỨU GIAO THỨC OAUTH VÀ
ỨNG DỤNG TRONG XÁC THỰC

LUẬN VĂN THẠC SĨ NGÀNH CÔNG NGHỆ THÔNG TIN

Hà Nội - 2014


ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN HỒNG NHUNG

NGHIÊN CỨU GIAO THỨC OAUTH VÀ
ỨNG DỤNG TRONG XÁC THỰC

Ngành: Công nghệ thông tin
Chuyên ngành: Hệ thống thông tin
Mã số: 60480104

LUẬN VĂN THẠC SĨ NGÀNH CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS. NGUYỄN HẢI CHÂU

Hà Nội - 2014

3

Lời cam đoan
Tôi xin cam đoan đây là công trình nghiên cứu của riêng tôi.
Các số liệu, kết quả nêu trong luận văn là trung thực và chưa từng được ai công
bố trong bất kỳ công trình nào khác.
Tôi xin kính gửi lời cảm ơn chân thành tới các thầy cô trường Đại học Công
nghệ, đã tận tình giảng dạy và giúp đỡ tôi trong suốt thời gian học vừa qua. Nhờ các
thầy cô, tôi đã tích lũy thêm được nhiều kiến thức cho bản thân cả về kiến thức chuyên
môn lẫn kiến thức xã hội.
Trong quá trình hoàn thành luận văn, ngoài những cố gắng của chính bản thân,
tôi cũng đã nhận được sự giúp đỡ rất nhiều từ gia đình, các anh chị đi trước và của tất
cả bạn bè.
Tôi xin gửi lời cảm ơn chân thành nhất tới thầy Nguyễn Hải Châu - thầy đã
trực tiếp hướng dẫn, giúp đỡ, chỉ bảo tôi nhiệt tình, để tôi có thể hoàn thành luận văn
cao học của mình.
Hà Nội, tháng 10 năm 2014
Tác giả

Nguyễn Hồng Nhung


4

Mục lục
Lời cam đoan ...................................................................................................................3
Mục lục ............................................................................................................................4
Danh mục các kí hiệu và chữ viết tắt ..............................................................................6
Danh mục các hình vẽ và đồ thị ......................................................................................7

MỞ ĐẦU .........................................................................................................................8
Chương 1. TỔNG QUAN VỀ XÁC THỰC ....................................................................9
1.1. Khái niệm ..............................................................................................................9
1.2. Các phương thức xác thực ....................................................................................9
1.2.1. Xác thực dựa theo tri thức ............................................................................10
1.2.2. Xác thực dựa theo sự sở hữu ........................................................................10
1.2.3. Xác thực dựa theo sinh trắc học ...................................................................10
1.3. Các giao thức xác thực ........................................................................................10
Chương 2. GIAO THỨC XÁC THỰC OAUTH VÀ OPENID ....................................13
2.1. Giao thức xác thực OAuth ..................................................................................13
2.1.1. Khái niệm .....................................................................................................13
2.1.2. Ứng dụng ......................................................................................................14
2.1.3. Cách thức hoạt động.....................................................................................14
2.2. Giao thức OpenID ...............................................................................................17
2.2.1. Khái niệm .....................................................................................................17
2.2.2. Cách thức hoạt động.....................................................................................17
2.3. Sự khác biệt giữa OAuth và OpenID ..................................................................19
2.4. Sự khác biệt giữa OAuth với một số giao thức xác thực người dùng khác. .......20
Chương 3. XÂY DỰNG ỨNG DỤNG KẾT NỐI FACEBOOK THÔNG QUA GIAO
THỨC OAUTH .............................................................................................................22
3.1. Mạng xã hội Facebook ........................................................................................22
3.1.1. Giới thiệu......................................................................................................22
3.1.2. Ứng dụng trên Facebook .............................................................................22
3.1.3. Facebook API ...............................................................................................23


5

3.1.4. Cách đăng kí ứng dụng trên Facebook .........................................................27
3.2. Phát triển ứng dụng với Drupal ..........................................................................30

3.2.1. Giới thiệu Drupal .........................................................................................30
3.2.2. Cách xây dựng một module cho Drupal ......................................................31
3.2.2.1. Các khái niệm cơ bản. ...........................................................................31
3.2.2.2. Các bước xây dựng module. ..................................................................33
3.2.3. Cách quản lý người dùng của Drupal ..........................................................42
3.3. Xây dựng ứng dụng kết nối Facebook dựa trên giao thức OAuth ......................44
3.3.1. Môi trường thực nghiệm ứng dụng ..............................................................44
3.3.2. Xây dựng và thiết lập chức năng Login/Register cho Drupal thông qua tài
khoản Facebook .....................................................................................................44
3.3.3. Xây dựng và thiết lập chức năng cho phép người dùng chia sẻ liên kết lên
tường Facebook từ Drupal. ....................................................................................50
KẾT LUẬN ...................................................................................................................56
TÀI LIỆU THAM KHẢO .............................................................................................57


6

Danh mục các kí hiệu và chữ viết tắt

Từ viết tắt

Cụm từ đầy đủ

API

Application Programming Interface

CHAP

Challenge-Handshake Authentication Protocol

CMF

Content management framework

CMS

Content management system

EAP

Extensible Authentication Protocol

FB

Facebook

FBML

Facebook Markup Language

FQL

Facebook Query Language

LAMP

Linux+Apache+MySql+PHP

IdP

Identity Provider

OAuth

Open Authentication

PAP

Password Authentication Protocol

PIN

Personal Identification Number

RADIUS

Remote Authentication Dial-In Use Service

RP

Relying Party

URI

Uniform Resource Identifier

URL

Uniform Resource Locator

7

Danh mục các hình vẽ và đồ thị

Hình 1.1. Phân loại các phương thức xác thực ................................................................9
Hình 2.1. Ví dụ về cách OAuth 2.0 được sử dụng để chia sẻ dữ liệu .......................13
Hình 2.2. Hoạt động của 3-legged OAuth .....................................................................16
Hình 2.3. Hoạt động của 2-legged OAuth .....................................................................16
Hình 2.4. Cách hoạt động của OpenID..........................................................................19
Hình 2.5. Sự khác biệt trong việc sử dụng OAuth so với OpenID................................20
Hình 3.1. Hộp thoại đa phương thức .............................................................................25
Hình 3.2. Cách thức hoạt động của Facebook API .......................................................26
Hình 3.3. Tạo ứng dụng Facebook ................................................................................28
Hình 3.4. Điền thông tin ứng dụng Facebook ...............................................................28
Hình 3.5. Kiểm tra bảo mật ...........................................................................................28
Hình 3.6. Trang quản lý ứng dụng .................................................................................29
Hình 3.7. Công khai ứng dụng Facebook ......................................................................30
Hình 3.8. Minh họa giao diện hiển thị tên module ........................................................34
Hình 3.9. Danh sách quyền trong Drupal ......................................................................43
Hình 3.10. Cách hoạt động của oafb .............................................................................45
Hình 3.11. Trang cấu hình module oafb ........................................................................46
Hình 3.12. Cách hoạt động của ShareFB ......................................................................50
Hình 3.13. Giao diện Drupal sau khi cài đặt module oafb và ShareFB ........................53
Hình 3.14. Trang xác thực của Facebook ......................................................................54
Hình 3.15. Trang cá nhân của người dùng Drupal ........................................................54
Hình 3.16. Ứng dụng chia sẻ liên kết ............................................................................55
Hình 3.17. Tường Facebook của người dùng ................................................................55

8

MỞ ĐẦU
Với sự phát triển nhanh chóng của hệ thống mạng và các ứng dụng như thương
mại điện tử, nhu cầu về bảo mật máy tính hiệu quả ngày càng tăng. Hầu hết các hệ
thống máy tính được bảo vệ thông qua một quá trình nhận dạng người dùng và xác
thực. Trong khi nhận dạng, người dùng cung cấp các thông tin để xác định chính mình,
các thông tin này có thể được biết đến bởi các quản trị hệ thống và những người sử
dụng hệ thống khác, còn với xác thực thì người dùng phải cung cấp các thông tin cá
nhân bí mật để có thể xác nhận danh tính.
Có nhiều giao thức, phương pháp và kĩ thuật xác thực khác nhau. Trong luận
văn này, tôi tập trung nghiên cứu giao thức OAuth, từ đó xây dựng ứng dụng thử
nghiệm đăng ký và xác thực người dùng trên Web sử dụng giao thức OAuth qua tài
khoản Facebook; cho phép người dùng chia sẻ liên kết lên tường Facebook.
Luận văn gồm các nội dụng như sau:
Mở đầu: Giới thiệu về đề tài luận văn, ý nghĩa và tính khả thi của đề tài.
Chương 1. Tổng quan về xác thực: Trình bày khái niệm, phương thức và giao
thức xác thực.
Chương 2. Giao thức xác thực OAuth và OpenID: Trình bày khái niệm và cách
thức hoạt động của các giao thức OAuth và OpenID.
Chương 3. Xây dựng ứng dụng kết nối Facebook thông qua giao thức OAuth:
Trình bày các vấn đề liên quan đến việc cài đặt và triển khai ứng dụng. Kết quả đạt
được khi chạy thử.
Kết luận: Trình bày tóm tắt các kết quả đạt được. Hướng mở rộng, phát triển
hệ thống.


9

Chương 1. TỔNG QUAN VỀ XÁC THỰC
Xác thực là một phần không thể thiếu được trong kiến trúc bảo mật của một
hệ thống bất kì. Chương này cung cấp cái nhìn tổng quan về xác thực, phân loại các
phương thức xác thực theo đặc điểm sử dụng và giới thiệu một số giao thức xác thực
cơ bản.
1.1. Khái niệm [11]
Xác thực (Authentication) là một hành động nhằm chứng thực một cái gì đó
(hoặc một người nào đó) đáng tin cậy, nghĩa là những lời khai báo do người đó đưa ra
hoặc về vật đó là sự thật. Xác thực một đối tượng còn có nghĩa là công nhận nguồn
gốc của đối tượng, trong khi, xác thực một người thường là thẩm tra nhận dạng họ.
Xác thực liên quan đến nhiều lĩnh vực nhưng trong khoa học máy tính, xác thực
là quá trình mà một hệ thống xác minh danh tính của người dùng nào đó muốn truy
cập vào nó, để đảm bảo quyền truy cập vào hệ thống hay dữ liệu bí mật trong nó.
Xác thực có thể được thực hiện bằng thẻ thông minh, hoặc Authentication
Server hoặc cơ sở hạ tầng khóa công khai... nhưng thông dụng nhất là sử dụng tài
khoản với tên người dùng và mật khẩu. Xác thực là điều cần thiết để bảo mật hệ thống
hiệu quả.
1.2. Các phương thức xác thực [9]
Các phương thức xác thực có thể phân thành 3 loại theo đặc điểm chúng được
sử dụng như trong hình 1.1.

Hình 1.1. Phân loại các phương thức xác thực


10

1.2.1. Xác thực dựa theo tri thức
Đây là phương thức sử dụng rộng rãi nhất hiện nay và đã trở nên quen thuộc
với người dùng.
Phương thức này sử dụng mật khẩu bằng dãy kí tự: từ, cụm từ hay câu; mật

khẩu bằng hình ảnh, nhận dạng khuân mặt hay sử dụng mã số cá nhân (PINs). Đối
với mạng công cộng không bảo đảm, để xác thực thì chứng thư số và chữ kí số được
sử dụng.
1.2.2. Xác thực dựa theo sự sở hữu
Xác thực dựa theo sự sở hữu (hay xác thực dựa theo thẻ) sẽ dựa vào những gì
mà người dùng có, chủ yếu là các đối tượng vật lý, chẳng hạn như thẻ. Tồn tại của
phương thức này là thẻ không chứng minh được quyền sở hữu vì nó dễ dàng bị đánh
cắp hoặc được nhân đôi bởi các phương tiện gian lận tinh vi.
Thẻ nhớ sản xuất không tốn kém. Sử dụng thẻ nhớ với cơ chế xác thực dựa trên
tri thức chẳng hạn như mã PIN sẽ bảo mật hơn nhiều so với việc dùng thẻ hay mã PIN
đơn lẻ.
1.2.3. Xác thực dựa theo sinh trắc học
Đây là phương thức dựa trên các đặc điểm sinh lý hay hành vi của người dùng,
đó là các thuộc tính vật lý ổn định của họ như: vân tay, võng mạc, khuân mặt, giọng
nói, loại máu, những chi tiết sinh học nhỏ trên cơ thể người dùng…
Phương thức này đem lại hiệu quả bảo mật rất cao vì nó không dễ dàng bị đánh
cắp hoặc được chia sẻ, tuy nhiên nó không được sử dụng phổ biến và chủ yếu được sử
dụng trong các hệ thống với mức độ bảo mật rất cao vì:
- Tốn kém: yêu cầu phần cứng đặc biệt.
- Được cho là có thể xâm lấn về quyền riêng tư.
- Có thể bị phân tích và một lần bị đánh cắp thì không thể được sử dụng nữa.
1.3. Các giao thức xác thực [11]
Giao thức xác thực là loại giao thức mã hóa với mục đích chứng thực các thực
thể có nhu cầu giao tiếp an toàn.
Hiện nay có rất nhiều các giao thức xác thực được sử dụng như: PAP, CHAP,
EAP, RADIUS, HIP, KERBEROS, PEAP...
 Giao thức PAP (Password Authentication Protocol): là một giao thức xác thực
đơn giản, trong đó tên người dùng và mật khẩu sẽ được gửi đến máy chủ truy cập từ xa
dưới dạng bản rõ để xác thực. Sử dụng PAP là không an toàn vì mật khẩu có thể dễ
dàng đọc được từ các gói tin trao đổi trong quá trình xác thực. Vì thế PAP thường được

11

sử dụng như một phương sách cuối cùng khi các máy chủ từ xa không hỗ trợ giao thức
xác thực mạnh hơn.
 Giao thức CHAP (Challenge-Handshake Authentication Protocol): là một giao
thức bắt tay ba chiều bởi vì nó bao gồm ba bước để thực hiện kiểm tra một kết nối sau
khi kết nối được khởi tạo đầu tiên, hay tại bất kỳ thời điểm nào sau khi kết nối được
thiết lập.
Với CHAP, máy chủ truy cập từ xa sẽ gửi một thử thách cho máy khách truy
cập từ xa. Các máy khách này sử dụng một thuật toán băm (còn gọi là hàm băm) để
tính toán một Message Digest-5 (MD5) dựa vào các thử thách và kết quả băm từ mật
khẩu của người dùng. Các máy khách sẽ gửi kết quả băm MD5 cho máy chủ truy cập
từ xa. Các máy chủ truy cập từ xa cũng có quyền truy cập vào kết quả băm từ mật
khẩu người dùng, thực hiện các tính toán tương tự bằng thuật toán băm và so sánh kết
quả với kết quả mà máy khách gửi. Nếu kết quả phù hợp, các thông tin của máy khách
truy cập từ xa được coi là đáng tin cậy.
Vì thuật toán băm cung cấp mã hóa một chiều, có nghĩa là tính toán kết quả
băm cho một khối dữ liệu là dễ dàng, nhưng việc xác định khối dữ liệu ban đầu từ kết
quả băm là không khả thi toán học, hơn nữa thử thách là ngẫu nhiên, nên giao thức
CHAP cung cấp một lá chắn có hiệu quả chống lại sự tấn công lặp lại.
 Giao thức KERBEROS: là một giao thức mật mã dùng để xác thực trong các
mạng máy tính hoạt động trên những đường truyền không an toàn. Giao thức Kerberos
có khả năng chống lại việc nghe lén hay gửi lại các gói tin cũ và đảm bảo tính toàn vẹn
của dữ liệu. Mục tiêu khi thiết kế giao thức này là nhằm vào mô hình máy chủ-máy
khách (Client-Server) và đảm bảo nhận thực cho cả hai chiều.
Giao thức được xây dựng dựa trên mã hóa khóa đối xứng và cần đến một bên
thứ ba tham gia vào quá trình nhận thực gọi là "trung tâm phân phối khóa" (tiếng Anh:
key distribution center - KDC). KDC bao gồm hai chức năng: "máy chủ xác thực"

(Authentication Server - AS) và "máy chủ cung cấp vé" (ticket granting Server - TGS).
"Vé" trong hệ thống Kerberos chính là các chứng thực chứng minh tính hợp lệ của
người dùng.
Mỗi người dùng (cả máy chủ và máy khách) trong hệ thống chia sẻ một khóa
chung với máy chủ Kerberos. Việc sở hữu thông tin về khóa chính là bằng chứng để
chứng minh tính hợp lệ của một người dùng. Trong mỗi giao dịch giữa hai người
dùng trong hệ thống, máy chủ Kerberos sẽ tạo ra một khóa phiên dùng cho phiên
giao dịch đó. Đây là một trong những giao thức được sử dụng rộng rãi nhất trong
môi trường mạng.


12

 Giao thức RADIUS (Remote Authentication Dial-In Use Service): Là một trong
những giao thức mạng lâu đời nhất, giúp xác thực, ủy quyền, quản lý người dùng kết
nối và sử dụng dịch vụ mạng. Nó thường được sử dụng bởi các ISP và các doanh
nghiệp để quản lý truy cập vào Internet hay mạng nội bộ, mạng không dây và các dịch
vụ e-mail tích hợp. Các mạng lưới này có thể kết hợp modem, DSL, các điểm truy cập,
mạng riêng ảo, cổng mạng hay máy chủ web...
RADIUS chạy như một chương trình phần mềm trên máy chủ. Các máy chủ
thường được sử dụng dành riêng cho xác thực RADIUS. Khi người dùng cố gắng kết
nối vào mạng, chương trình máy khách RADIUS hướng tất cả dữ liệu người dùng tới
máy chủ RADIUS để xác thực. Các máy chủ lưu trữ dữ liệu người dùng để xác thực
dưới dạng mã hóa và gửi phản hồi lại nền kết nối. Xác thực được thiết lập hoặc bị từ
chối. Nếu bị từ chối, người dùng thử lại. Nếu xác thực được thiết lập, sự tương tác
RADIUS kết thúc. Dịch vụ mạng yêu cầu xác thực được xử lý bởi các giao thức khác
nếu cần thiết.
 Giao thức EAP (Extensible Authentication Protocol): là giao thức truyền thông
được sử dụng thông qua các loại cơ chế xác thực khác nhau, chẳng hạn như thẻ token,
Kerberos, mật khẩu một lần, giấy chứng nhận, xác thực khóa công khai và các thẻ

thông minh... Trong giao tiếp không dây sử dụng EAP, người dùng muốn kết nối vào
một mạng WLAN thông qua một AP, AP sẽ yêu cầu danh tính của người sử dụng và
truyền danh tính này đến một máy chủ xác thực như RADIUS. Các máy chủ yêu cầu
AP cho các thông tin nhận được từ người sử dụng, gửi lại cho máy chủ để hoàn tất
việc xác thực.
Ngoài các giao thức xác thực trên còn có nhiều giao thức xác thực khác, nhưng
trong các ứng dụng web thì được sử dụng phổ biến là có hai giao thức OAuth và
OpenID. Hai giao thức này sẽ được trình bày ở chương kế tiếp.


13

Chương 2. GIAO THỨC XÁC THỰC OAUTH VÀ OPENID
Có rất nhiều giao thức xác thực trên internet: Google AuthSub, AOL OpenAuth,
Yahoo BBAuth, Facebook Auth, Upcoming API, Flickr API, Amazon Web Services
API… cho lập trình viên khi phát triển ứng dụng web. Nhưng phổ biến hiện nay là
giao thức OAuth và OpenID vì chúng tuân theo chuẩn chung và có rất nhiều ưu điểm.
2.1. Giao thức xác thư ̣c OAuth
2.1.1. Khái niệm [11, 14]
OAuth là một giao thức mở để xác thực. OAuth cung cấp cho các máy khách
phương pháp truy cập tài nguyên của máy chủ. Đồng thời OAuth cho phép người sử
dụng xác thực việc sử dụng tài nguyên của bên thứ ba mà không làm lộ các thông tin
bí mật như tên người sử dụng, mật khẩu v.v.. OAuth cơ bản sử dụng “access token”
cấp cho máy khách bởi một máy chủ ủy quyền, với sự chấp thuận của chủ sở hữu
nguồn tài nguyên. Các máy khách sau đó sử dụng “access token” để truy cập các
nguồn tài nguyên được bảo vệ trên máy chủ tài nguyên.
Ví dụ, một ứng dụng trò chơi có thể truy cập vào dữ liệu người sử dụng trong
các ứng dụng Facebook, hoặc một ứng dụng dựa trên địa điểm có thể truy cập dữ liệu
người sử dụng của ứng dụng Foursquare... Hình 2.1 minh họa cho khái niệm trên.

Hình 2.1. Ví dụ về cách OAuth 2.0 được sử dụng để chia sẻ dữ liệu
OAuth được phát triển từ 11/2006. Do sự tiện lợi, OAuth đang được phát triển
lên các phiên bản cao hơn. Hiện nay, OAuth 2.0 thay thế cho OAuth 1.0. OAuth 1.0
phức tạp hơn, nó yêu cầu các giấy chứng nhận liên quan. OAuth 2.0 đơn giản hơn, nó
không đòi hỏi tất cả giấy chứng nhận mà chỉ cần SSL/TLS.


14

2.1.2. Ứng dụng [6]
OAuth được ứng dụng nhiều trong việc xác thực trên Internet, truy cập một cửa
trong các hệ thống phức tạp v.v.. và người dùng không phải lo lắng về thông tin truy
cập của họ đang bị tổn hại.
Các chức năng trong OAuth cho phép:
-

Tiếp cận được đồ thị xã hội của người dùng (bạn bè của họ trên Facebook,
Twitter hoặc Google Contacts...)

-

Chia sẻ thông tin về các hoạt động của người dùng trên trang web của nhà
phát triển ứng dụng, bằng cách gửi bài đến tường trên Facebook hoặc dòng
thời gian của Twitter...

-

Truy cập vào tài khoản Google Docs hay Dropbox của người dùng để lưu
trữ dữ liệu trong hệ thống tập tin trực tuyến của họ.

-

Tích hợp các ứng dụng thương mại với nhau.

Vì thế, OAuth có thể được sử dụng hoặc để tạo ra ứng dụng đọc dữ liệu người
dùng từ một ứng dụng khác (ví dụ như các trò chơi trong sơ đồ trên), hoặc ứng dụng
cho phép các ứng dụng khác truy cập vào dữ liệu người dùng của nó (ví dụ như
Facebook trong ví dụ trên)...
2.1.3. Cách thức hoạt động [16]
OAuth được sử dụng để một ứng dụng máy khách có thể truy cập vào các
nguồn tài nguyên được lưu trữ trên máy chủ tài nguyên. Để hiểu hơn về cách hoạt
động của OAuth, ta làm rõ một số khái niệm:
Resource Owner: là người hoặc ứng dụng sở hữu nguồn tài nguyên được bảo vệ.
OAuth Client: là ứng dụng có yêu cầu truy cập vào các nguồn tài nguyên
được bảo vệ.
Resource Server: là máy chủ lưu trữ các nguồn tài nguyên được bảo vệ mà
OAuth Client muốn truy cập.
Authorization Server: là máy chủ cho phép OAuth Client truy cập tài
nguyên của chủ sở hữu tài nguyên. Resource Server và Authorization Server có
thể là cùng một máy chủ.
Client ID và Client secret: Client ID là một định danh duy nhất cho một
OAuth Client. OAuth Client sử dụng Client ID (client_ID) và Client secret
(client_secret) để cung cấp danh tính.


15

Access Token: là một định danh để truy cập vào các nguồn tài nguyên được bảo
vệ của chủ sở hữu tài nguyên. OAuth Client có thể sử dụng các Access Token trước
khi nó hết hạn.

Refesh Token: là một định danh để có được Access Token. Authorization
Server tạo ra Refesh Token cùng với Access Token. OAuth Client có thể sử dụng
Refesh Token để yêu cầu một Access Token mới từ Authorization Server khi Access
Token hiện tại hết hạn hoặc yêu cầu một Access Token với phạm vi trùng hoặc hẹp
hơn. Không giống Access Token, Refesh Token không được gửi đến Resource Server.
*) 3-legged OAuth:
3-legged OAuth là một mô hình truyền thống với sự tương tác của Resource
Owner. Trong trường hợp này, Resource Owner muốn cấp cho một Client truy cập vào
một Server mà không chia sẻ thông tin. Hình 2.2 cho thấy quá trình hoạt động của 3legged OAuth.
Hoạt động của 3-legged OAuth như sau:
1. Người dùng - Resource Owner, bắt đầu một yêu cầu cho OAuth Client.
2. OAuth Client chuyển hướng Resource Owner đến Authorization Server
3. Resource Owner xác nhận và cho phép tùy chọn với Authorization Server.
4. Authorization Server đưa ra một form để Resource Owner cấp quyền truy cập.
5. Resource Owner đệ trình form cho phép hoặc từ chối truy cập.
6. Dựa vào những phản hồi của Resource Owner, có hai trường hợp xảy ra:
- Nếu Resource Owner cho phép truy cập, Authorization Server sẽ
chuyển hướng OAuth Client với một mã ủy quyền.
- Nếu Resource Owner từ chối truy cập, OAuth Client vẫn được chuyển
hướng nhưng không được cấp mã ủy quyền.
7. OAuth Client gửi các thông tin sau cho Authorization Server:
- Authorization grant code (mã ủy quyền)
- Client ID
- Client secret hoặc Client certificate
8. Nếu được xác nhận, Authorization Server gửi cho OAuth Client một Access
Token và một Refesh Token tùy ý.


16

Hình 2.2. Hoạt động của 3-legged OAuth
9. OAuth Client gửi Access Token tới Resource Server để yêu cầu nguồn tài
nguyên được bảo vệ.
10. Nếu Access Token hợp lệ với tài nguyên được yêu cầu thì OAuth Client có
thể truy cập nguồn tài nguyên được bảo vệ đó.
*) 2-legged OAuth:
2-legged OAuth hoạt động như một Client-Server điển hình, mà không cần sự
tham gia của Resource Owner. Ví dụ, một ứng dụng Client Facebook truy cập vào tài
khoản Facebook.
2-legged OAuth hoạt động đơn giản như sau:
1. OAuth Client bắt đầu yêu cầu với một Authorization Server và nhận một
Access Token.
2. OAuth Client sử dụng Access Token để truy cập tài nguyên được bảo vệ trên
Resource Server.
Hình 2.3 cho thấy quá trình hoạt động của 2-legged OAuth.

Hình 2.3. Hoạt động của 2-legged OAuth


17

2.2. Giao thức OpenID
2.2.1. Khái niệm [11]
OpenID là một giao thức xác thực, cho phép người dùng sử dụng một tài khoản
để đăng nhập vào nhiều trang web, mà không cần phải tạo mật khẩu mới.
Với OpenID, người dùng có thể kiểm soát lượng thông tin được chia sẻ với các
trang web mà họ truy cập. Mật khẩu của người dùng được đưa cho nhà cung cấp danh
tính, và nhà cung cấp này sau đó sẽ xác nhận danh tính của người dùng đến các trang
web mà họ truy cập. Khác với nhà cung cấp danh tính, không có trang web nào có thể
nhìn thấy mật khẩu của họ, vì vậy, không cần phải lo lắng về một trang web vô đạo

đức hoặc không an toàn ảnh hưởng đến danh tính của người dùng.
OpenID được tạo ra vào năm 2005, bởi một cộng đồng mã nguồn mở, cố gắng
giải quyết vấn đề không dễ giải quyết bằng công nghệ nhận dạng hiện có lúc bấy giờ.
OpenID không thuộc sở hữu của bất kì ai. Hiện nay, ai cũng có thể sử dụng một
OpenID hoặc trở thành một nhà cung cấp OpenID miễn phí mà không cần phải đăng kí
hoặc được sự chấp thuận của bất kì tổ chức nào.
Vào tháng 2 năm 2014, thế hệ thứ ba của công nghệ OpenID là OpenID
Connect ra đời. Nó là lớp xác thực đơn giản phần đầu của giao thức OAuth 2.0.
OpenID Connect thực hiện nhiều nhiệm vụ giống với OpenID 2.0 nhưng thân thiện
hơn. Cơ chế tùy chọn ký và mã hóa mạnh mẽ được định nghĩa bởi OpenID Connect.
Không giống như OpenID 2.0, OpenID Connect tích hợp khả năng OAuth 2.0 với giao
thức riêng của mình và không cần phần mở rộng.
2.2.2. Cách thức hoạt động [11, 18]
Để hiểu về cách hoạt động của OpenID, ta làm rõ một số khái niệm:
Relying Party (RP) hay còn gọi là “Consumer”: là một trang web hoặc ứng
dụng mà muốn xác nhận danh tính người dùng.
Identity Provider (IdP) còn gọi là OpenID Server: Là một hệ thống tạo, duy
trì và quản lý các thông tin nhận dạng, là một dịch vụ chuyên về đăng ký OpenID URL
hoặc XRI. OpenID cho phép người dùng giao tiếp với RP. Giao tiếp này được thực
hiện thông qua việc trao đổi thông tin nhận dạng hoặc OpenID (là URL hoặc XRI
được lựa chọn bởi người dùng để đặt tên cho danh tính của họ). IdP cung cấp xác thực
OpenID để các ứng dụng khác có thể nhận dạng. Việc trao đổi được kích hoạt bởi một


18

User-agent, đó là chương trình (chẳng hạn như một trình duyệt) được sử dụng bởi
người dùng để giao tiếp với RP và IdP.
Ví dụ, nếu một trang web cho phép đăng nhập thông qua Facebook hay
Google... thì Facebook, Google chính là các OpenID Server.

Giả sử rằng người dùng chưa đăng nhập vào OpenID Server. OpenID hoạt động
như sau:
1. Người dùng nhận form đăng nhập OpenID từ Consumer.
2. Người dùng phản hồi bằng URL đại diện cho OpenID của họ.
3. Consumer chuyển đổi OpenID URL thành dạng chuẩn và sử dụng để yêu cầu
một tài liệu từ Identity Server.
4. Identity Server trả về tài liệu HTML được đặt tên bởi OpenID URL.
5. Consumer kiểm tra tiêu đề tài liệu HTML với thẻ <link/>, thuộc tính rel thiết
lập openid.server và tùy chọn openid.delegate. Consumer sử dụng các giá trị trong các
thẻ này để xây dựng một URL với chế độ checkid_setup cho Identity Server và chuyển
hướng User Agent. Chekid_setup URL mã hóa, trong đó, một URL để quay trở lại
trong trường hợp thành công và một URL để trở lại trong trường hợp thất bại hoặc hủy
bỏ yêu cầu.
6. OpenID Server trả về một màn hình đăng nhập.
7. Người dùng nhập ID và password đăng nhập và gửi cho OpenID Server.
8. OpenID Server sẽ trả về một form ủy thác tới người dùng hỏi họ có tin tưởng
vào Consumer (xác định bởi URL) với danh tính của họ hay không.
9. Người dùng gửi phản hồi tới OpenID Server.
10. Người dùng sẽ được chuyển hướng tới một trong hai URL thành công hoặc
URL thất bại ở bước 5 tùy thuộc vào phản hồi của người dùng.
11. Consumer trả về trang thích hợp cho người dùng tùy thuộc vào hoạt động
mã hóa trong các URL chỉ ra ở bước 10.
Hình 2.4 cho thấy cách mà OpenID hoạt động. Nếu người dùng đã đăng nhập
vào OpenID Server thì bước 6 và 7 là không cần thiết.


19

Hình 2.4. Cách hoạt động của OpenID
2.3. Sự khác biệt giữa OAuth và OpenID [11]

Nói “Sự khác biệt giữa OAuth và OpenID” là chưa đầy đủ, vì OAuth và
OpenID hiện nay đã có nhiều phiên bản. Ở đây nói đến điểm khác nhau chung nhất
giữa chúng.
OpenID và OAuth đều là các giao thức xác thực, nhưng OpenID sử dụng một
tập hợp các thông tin người dùng để truy cập vào nhiều trang web, OAuth có thêm tính
năng cho phép một trang web truy cập và sử dụng thông tin liên quan đến tài khoản
của người dùng trên một trang web khác.
Hình 2.5 nhấn mạnh sự khác biệt giữa việc sử dụng OpenID so với OAuth để
xác thực. Với OpenID, quá trình này bắt đầu với các ứng dụng yêu cầu người dùng
cung cấp danh tính của họ. Với OAuth, các ứng dụng yêu cầu một giới hạn truy cập
OAuth Token (valet key) để truy cập các API (enter the house) thay mặt cho người
dùng. Nếu người dùng có thể cấp quyền truy cập đó, các ứng dụng có thể lấy định
danh duy nhất cho việc thiết lập hồ sơ cá nhân (identity) sử dụng các API.


20

Hình 2.5. Sự khác biệt trong việc sử dụng OAuth so với OpenID
2.4. Sự khác biệt giữa OAuth với một số giao thức xác thực người dùng khác.
 OAuth so với Google AuthSub và Yahoo BBAuth
Giống:
 Người dùng phải cho phép ứng dụng truy cập dữ liệu của người dùng
 Các giao thức đều sử dụng token, một token tạm thời đầu tiên để cho
phép ủy quyền và một token khác để chứa thông tin người dùng.
Khác:
 Trong khi OAuth và BBAuth cần đến Client ID và Client Secret thì
AuthSub có thể cần hoặc không cần.
 BBAuth là giao thức xác thực người dùng của Yahoo, AuthSub là giao
thức xác thực người dùng của Google. Còn OAuth được hỗ trợ rộng rãi
bởi nhiều cá nhân và tổ chức.

 AuthSub chỉ dùng trong Google API, BBAuth chỉ dùng trong Yahoo
API, còn OAuth không chỉ được dùng trong Google API, Yahoo API mà
còn được dùng trong các API khác như: Amazon, Facebook, Twitter...


21

 OAuth hỗ trợ các ứng dụng không chỉ trên web mà còn trên máy tính để
bàn, điện thoại di động..., trong khi BBAuth và AuthSub chỉ hỗ trợ các
ứng dụng trên nền web.
 OAuth so với SAML
Giống:

 SAML và OAuth là một trong những giao thức/chuẩn được sử dụng
nhiều nhất cho các ứng dụng đăng nhập một lần.
 Giúp xác thực người dùng và ủy quyền truy cập dữ liệu.
 Được nhiều cá nhân, tổ chức hỗ trợ và phát triển.

Khác:
 SAML sử dụng định dạng thẻ XML, còn OAuth sử dụng định dạng thẻ
binary hoặc JSON.
 Giao thức truyền thông mà SAML sử dụng là HTTP (redirect, post,
artifact), SOAP, PAOS; còn OAuth chỉ sử dụng HTTP.
 OAuth được thiết kế để sử dụng với các ứng dụng trên Internet, máy tính
để bàn, điện thoại di động; còn SAML chủ yếu được dùng cho các ứng
dụng liên quan đến doanh nghiệp.
Chương này đã cho thấy cách hoạt động của OAuth trong ứng dụng web.
Những hiểu biết về giao thức OAuth sẽ được sử dụng để xây dựng ứng dụng kết nối
Facebook trong chương tiếp theo.

22

Chương 3. XÂY DỰNG ỨNG DỤNG KẾT NỐI FACEBOOK THÔNG
QUA GIAO THỨC OAUTH
Chương này trình bày các vấn đề liên quan đến việc xây dựng một ứng dụng kết
nối với Facebook, trong đó có hai chức năng, thứ nhất là cho phép người dùng đăng
nhập hoặc đăng kí tài khoản Drupal thông qua tài khoản Facebook, thứ hai là cho phép
người dùng chia sẻ liên kết và đăng bình luận từ Drupal lên tường Facebook.
3.1. Mạng xã hội Facebook
3.1.1. Giới thiệu [11]
Facebook là một mạng xã hội, giúp người dùng dễ dàng kết nối và chia sẻ với
gia đình, bạn bè trực tuyến của họ.
Facebook cho phép người dùng gửi tin nhắn và cập nhật trạng thái mới hoặc chia
sẻ các nội dung khác như hình ảnh, liên kết... Facebook được thiết kế để cởi mở hơn và
xã hội hơn các công cụ truyền thông truyền thống. Không giống như email hay tin nhắn
tức thời, chúng rất riêng tư, còn những điều mà người dùng chia sẻ trên Facebook thì
được nhìn thấy bởi nhiều người khác. Facebook cũng cung cấp các công cụ bảo mật để
giúp người dùng hạn chế những người có thể nhìn thấy điều mà họ chia sẻ.
Facebook được tạo bởi Mark Zuckerberg vào năm 2004, trong khi ông đang
theo học tại Đại học Harvard. Ban đầu, nó được thiết kế cho sinh viên đại học. Đến
năm 2006, bất cứ ai trên 13 tuổi với một địa chỉ email hợp lệ có thể tham gia
Facebook. Đến nay, Facebook là mạng xã hội lớn nhất thế giới, với tỷ người dùng. Từ
khi Facebook phổ biến, các trang web khác đã làm việc để tích hợp Facebook. Điều
này có nghĩa người dùng có thể sử dụng tài khoản Facebook duy nhất để đăng nhập
vào các dịch vụ khác nhau trên Web.
3.1.2. Ứng dụng trên Facebook [4]
Vì sự phổ biến mà Facebook đã thu hút được một số lượng lớn các nhà phát
triển ứng dụng, trong đó có những ứng dụng thu hút được rất nhiều người dùng và đạt
doanh thu rất cao.

Khi người dùng bắt đầu lập trang trên Facebook, sẽ có vài ứng dụng cơ bản của
Facebook ở cột bên trái. Những ứng dụng này do chính hãng Facebook cung cấp bao
gồm Ảnh (Photos), Phim (Videos), Liên kết (Links), Sự kiện (Events) và Ghi chú
(Notes). Ứng dụng của bên thứ ba, không phải Facebook tạo ra, có thể được cài đặt
thêm trên trang Facebook.
Theo các nhà phát triển ứng dụng, ứng dụng trên Facebook có thể được liệt kê
như sau:


23



Alerts



File sharing



Photo



Business



Food and Drink



Politics



Chat



Gaming



Sports



Classified



Just for fun



Travel



Dating



Messaging



Utility



Education



Mobile



Video



Events



Money



Fashion



Music

3.1.3. Facebook API [8, 10]
Năm 2007, Facebook cho ra mắt Facebook platform, cung cấp cho các nhà phát
triển một công cụ để xây dựng các ứng dụng chạy trên Facebook, có khả năng tương
tác và tích hợp với các tính năng cốt lõi của Facebook. Facebook platform bao gồm
một ngôn ngữ đánh dấu dựa trên HTML được gọi là Facebook Markup Language
(FBML), một giao diện lập trình ứng dụng (API), một ngôn ngữ SQL theo kiểu truy
vấn để tương tác với Facebook gọi là Facebook Query Language (FQL), một ngôn ngữ
kịch bản được gọi là Facebook JavaScript để làm phong phú thêm trải nghiệm người
dùng, và một tập hợp các thư viện lập trình của máy khách (Facebook Client).
 Facebook Markup Language
Facebook Markup Language (FBML) là ngôn ngữ giống như HTML
được sử dụng để hiển thị các trang bên trong Facebook canvas.
- FBML chứa một tập con các thành phần của HTML
- FBML cung cấp các thành phần hỗ trợ cho kịch bản và tạo kiểu.
- Để phân biệt giữa HTML và FBML, sử dụng thẻ với tiền tố fb. Ví dụ,
để thêm một liên kết đến các trang trợ giúp của ứng dụng trên bảng điều khiển, ta chỉ
cần thêm những dòng sau đây:
<fb:dashboard>
href="help.php">Application
</fb:help>

</fb:dashboard>
 REST API Calls
Facebook API Call được nhóm lại thành các loại hành động sau:
- facebook.auth cung cấp cách xác thực người dùng Facebook.

Help


24

- facebook.feed cung cấp các phương thức để gửi tin đến tường Facebook.
- facebook.friends cung cấp các phương thức truy vấn Facebook để kiểm
tra sự khác nhau về bạn bè của người dùng.
- facebook.notifications cung cấp các phương thức để gửi tin nhắn cho
người dùng.
- facebook.profile cho phép thiết lập FBML trong profile của người dùng.
- facebook.users cung cấp thông tin về người dùng (chẳng hạn như nội
dung từ profile của người dùng cho dù họ đang đăng nhập).
- facebook.events cung cấp nhiều cách để truy cập các sự kiện Facebook.
- facebook.groups cung cấp các phương thức truy cập thông tin cho các
nhóm Facebook.
- facebook.photos cung cấp các phương thức để tương tác với hình ảnh
Facebook.
 Facebook Query Language
Facebook Query Language (FQL) là một ngôn ngữ kiểu SQL được thiết kế đặc
biệt để cho phép các nhà phát triển tương tác với thông tin Facebook. Facebook cho
phép tương tác với chín "table" riêng biệt để truy vấn thông tin trực tiếp, bao gồm:
user , friend , group , group_member , event ,
event_member , photo , album , phototag .
Để viết FQL, ta làm theo cú pháp SQL cơ bản. Ví dụ:

$friends = $facebook->api_client->fql_query(“SELECT
uid, name FROM
user WHERE
uid IN (SELECT uid2 FROM friend WHERE uid1=$user)”);
 Facebook JavaScript
Facebook triển khai thực hiện JavaScript riêng của nó cho các nhà phát triển
thực sự muốn và cần sử dụng JavaScript trong các ứng dụng của họ. Bằng cách sử
dụng Facebook JavaScript (FBJS), ta có thể làm phong phú thêm trải nghiệm của
người dùng.
Ví dụ, để cung cấp một hộp thoại đa phương thức cho người dùng:
Show Dialog Box</a>


25

Khi xử lý thông qua Facebook Platform, người dùng sẽ thấy hộp thoại đa phương
thức thể hiện trong hình 3.1 sau khi nhấp vào liên kết “Show Dialog Box”.

Hình 3.1. Hộp thoại đa phương thức
 Thư viện Client
Thư viện Client chính thức của Facebook với ngôn ngữ PHP và Java

cung cấp các phương thức tiện lợi để truy cập các ứng dụng Facebook. Để giúp các lập
trình viên phát triển ứng dụng Facebook riêng của mình, thư viện Client còn hỗ trợ
thêm

các

ngôn

ngữ

lập

trình

sau:

ActionScript,

ASP.Net,

ASP(VBScript), ColdFusion, C++, C#, D, Emacs Lisp, Lisp,
Perl, PHP(4 và 5), Python, Ruby, VB.Net và Windows mobile.
Thư viện Client với ngôn ngữ PHP của Facebook bao gồm 2 lớp chính:
Facebook

(Facebook.php)

và

FacebookRestClient

(facebook_api_php5_restlib.php). Lớp FacebookRestClient tóm tắt
các tương tác với API của Facebook. Lớp Facebook sử dụng các phương thức của
lớp FacebookRestClient để tóm tắt các tương tác phổ biến với Facebook
Platform.
 Cách thức hoạt động của Facebook API
Nói chung, các công cụ tạo nên Facebook platform được gọi là Facebook API.
Facebook API là một nền tảng để xây dựng những ứng dụng cho các thành viên của
mạng xã hội Facebook. API cho phép các ứng dụng sử dụng các kết nối xã hội và các
thông tin hồ sơ để làm cho các ứng dụng liên quan tới nhau nhiều hơn, và để phổ
biến các hoạt động tới trang cung cấp tin và trang hồ sơ của Facebook, tùy thuộc vào
cài đặt cá nhân của người dùng. Với API, người dùng có thể thêm hoàn cảnh xã hội
cho ứng dụng của họ bằng cách sử dụng hồ sơ cá nhân, bạn bè, thông báo, hình ảnh,
sự kiện hay bảng tin... API sử dụng giao thức RESTful và các hồi đáp được trả lại
dưới dạng XML.