1. Trang chủ
  2. » Luận Văn - Báo Cáo

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

57 12 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 57
Dung lượng 1,52 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

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

Trang 2

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

Trang 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

Trang 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

Trang 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

Trang 6

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

API Application Programming Interface CHAP Challenge-Handshake Authentication Protocol

EAP Extensible Authentication Protocol

PAP Password Authentication Protocol PIN Personal Identification Number RADIUS Remote Authentication Dial-In Use Service

Trang 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

Trang 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

Trang 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ả

Trang 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

Trang 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

Trang 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

Trang 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 xa ́ 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

Trang 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

Trang 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 3-legged 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 ý

Trang 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

Trang 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

Trang 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

Trang 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

Trang 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

 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

Trang 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

 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

Trang 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:

Trang 23

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>

<fb:help href="help.php">Application Help

</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

Trang 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

Ví dụ, để cung cấp một hộp thoại đa phương thức cho người dùng:

<a href="#" onclick="new Dialog().showMessage

link');return false">Show Dialog Box</a>

Trang 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_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

Trang 26

Hình 3.2 Cách thức hoạt động của Facebook API

- Ứng dụng Facebook không được cài đặt trực tiếp lên máy chủ Facebook Thay vào đó, chúng được đặt trên máy chủ của nhà phát triển và sau đó được gọi bởi Facebook khi URL ứng dụng được yêu cầu

- Để tương tác với các ứng dụng, Facebook sử dụng hàm gọi lại - là một URL

đã đăng ký liên quan đến ứng dụng

- Trong Facebook, khi URL ứng dụng Facebook được yêu cầu, Facebook chuyển hướng yêu cầu đến máy chủ APP Sau đó, APP sẽ xử lý yêu cầu, giao tiếp với

Facebook

Phương thức xác thực người dùng của Facebook API

REST API cung cấp hai phương thức chính để xử lý việc xác thực người dùng Phương thức facebook.auth.createToken() sẽ tạo ra một mã xác thực (auth_token) và chuyển tới cơ chế xác thực của Facebook Sau khi đăng nhập, phương thức thứ hai là facebook.auth.getSession() sẽ chứa mã này trong phản hồi chỉ khi có yêu cầu một auth_token cụ thể

Authentication cũng chính là trở ngại lớn cho các nhà phát triển ứng dụng trực tuyến Nếu thông qua Facebook, Facebook sẽ chịu trách nhiệm về việc xác thực người dùng, nhà phát triển không cần phải mua chứng chỉ SSL, thực hiện

sơ đồ mã hóa mật khẩu của riêng họ, hoặc thậm chí lo lắng về phiên làm việc của

người dùng

Trang 27

Phương thức đăng bài lên bảng tin người dùng của Facebook API

Bảng tin (feed) là một phần rất quan trọng của ứng dụng Facebook Chúng được sử dụng để đăng thông báo và tin tức trong hồ sơ người dùng Vì vậy, feed là cách tốt nhất để bạn bè của người sử dụng cập nhật hàng ngày về các hoạt động hiện tại của họ Feed cũng là một cách tuyệt vời để công bố công khai các ứng dụng của nhà phát triển

Có hai loại feed: news feed và mini feed News feed cập nhật tức thì hoạt động của bạn bè trực tuyến của người dùng Mini feed xuất hiện trên hồ sơ cá nhân và làm nổi bật hoạt động xã hội gần đây của người dùng

Facebook cung cấp ba phương thức để đăng tin lên news feed và mini feed Tuy nhiên, một người dùng chỉ có thể đăng tối đa là 10 lần trong vòng 48 giờ

◦ feed_publishStoryToUser(): Phương thức này dùng để đăng tin tới news feed của người sử dụng bất kì (giới hạn gọi một lần là 12 giờ)

◦ feed_publishActionOfUser(): Phương thức này dùng để đăng tin lên mini feed của người dùng và lên news feed của bạn bè người đó (giới hạn gọi 10 lần trong vòng 48 giờ)

◦ feed_publishTemplatizedAction(): Phương thức này cũng đăng lên news feed và mini feed nhưng theo một cách dễ dàng hơn (giới hạn gọi 10 lần trong một vòng 48 giờ)

3.1.4 Cách đăng kí ứng dụng trên Facebook [8, 10, 18]

Facebook cho phép tích hợp nó vào trang web của người dùng Để làm được điều này, Facebook coi các trang web đó như là các ứng dụng của mình, bằng cách sử dụng một App ID và App Secret cho mỗi trang Sau đây là cách để tạo một ứng

dụng trên Facebook:

Yêu cầu đăng kí ứng dụng trên Facebook:

Để tạo một ứng dụng trên Facebook, cần phải có một tài khoản Facebook đã được xác thực thông qua số di động, nếu tài khoản Facebook chưa được xác thực thì sẽ

không thể tạo được ứng dụng trên Facebook

Đăng ký làm nhà phát triển ứng dụng Facebook: (nếu đã thực hiện bước này thì

có thể chuyển sang bước tiếp theo)

- Login vào Facebook

- Đi đến trang http://facebook.com/developers/apps

- Bấm chọn “Register as a Developer” ở góc trên bên phải

- Chấp nhận các điều khoản của Facebook

Trang 28

- Xác minh tài khoản Facebook thông qua số điện thoại (nếu chưa làm)

Hình 3.4 Điền thông tin ứng dụng Facebook

- Nhập Captcha và nhấn nút gửi để hoàn thành việc tạo ứng dụng như trong hình 3.5

Hình 3.5 Kiểm tra bảo mật

Ngày đăng: 20/07/2021, 11:20

Nguồn tham khảo

Tài liệu tham khảo Loại Chi tiết
1. Trần Văn Lễ (2012), Phát triển ứng dụng kết nối Facebook trên cơ sở giao thức OAuth (Open Authentication), Luận văn thạc sĩ, Trường Đại học Công nghệ, Đại học Quốc gia Hà Nội.Tiếng Anh Sách, tạp chí
Tiêu đề: ), Phát triển ứng dụng kết nối Facebook trên cơ sở giao thức OAuth (Open Authentication)
Tác giả: Trần Văn Lễ
Năm: 2012
2. Jay Goldman (10-2008), Facebook Cookbook, Publisher: O’Reilly Media Sách, tạp chí
Tiêu đề: Facebook Cookbook
3. Matt Butcher (2008), Learning Drupal 6 Module Development. PACKT Publishing Sách, tạp chí
Tiêu đề: Learning Drupal 6 Module Development
Tác giả: Matt Butcher
Năm: 2008
4. Matt Butcher, Matt Farina, Ken Rickard, Greg Dunlap, Larry Garfield, John Albin Wilkins (2010), Drupal 7 Module Development. PACKT Publishing Sách, tạp chí
Tiêu đề: Drupal 7 Module Development
Tác giả: Matt Butcher, Matt Farina, Ken Rickard, Greg Dunlap, Larry Garfield, John Albin Wilkins
Năm: 2010
5. Richard Duncan (2001), An Overview of Different Authentication Methods and Protocols, Copyright SANS Institute, Author Retains Full Rights Sách, tạp chí
Tiêu đề: An Overview of Different Authentication Methods and Protocols
Tác giả: Richard Duncan
Năm: 2001
6. Ryan Boyd (2012), Getting Started with OAuth 2.0, Publisher: O’Reilly Media 7. Smith, R. E. (2002), Authentication: From passwords to public keys, Boston:Addison-Wesley Sách, tạp chí
Tiêu đề: Getting Started with OAuth 2.0", Publisher: O’Reilly Media 7. Smith, R. E. (2002), "Authentication: From passwords to public keys
Tác giả: Ryan Boyd (2012), Getting Started with OAuth 2.0, Publisher: O’Reilly Media 7. Smith, R. E
Năm: 2002
8. Shashwat Srivastava, Apeksha Singh (2011), Facebook Application Development with Graph API Cookbook. PACKT Publishing Sách, tạp chí
Tiêu đề: Facebook Application Development with Graph API Cookbook
Tác giả: Shashwat Srivastava, Apeksha Singh
Năm: 2011
9. Zippy Erlich, Moshe Zviran (2009), Authentication methods for Computer Systems Security, Category: IT Security &amp; Ethics Sách, tạp chí
Tiêu đề: Authentication methods for Computer Systems Security
Tác giả: Zippy Erlich, Moshe Zviran
Năm: 2009
10. Wayne Graham (2008), Facebook API Developers Guide, Publisher: Apress Sách, tạp chí
Tiêu đề: Facebook API Developers Guide
Tác giả: Wayne Graham
Năm: 2008

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

🧩 Sản phẩm bạn có thể quan tâm

w