BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
---------------------------------------

VŨ MẠNH CƯỜNG

HỆ THỐNG ĐĂNG NHẬP MỘT LẦN

Chuyên ngành : CÔNG NGHỆ THÔNG TIN

LUẬN VĂN THẠC SĨ KỸ THUẬT
CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC
1. PGS. TS. Nguyễn Linh Giang

Hà Nội – Năm 2019


LỜI CAM ĐOAN
Tôi – Vũ Mạnh Cường – xin cam đoan
• Luận văn tốt nghiệp (LVTN) Thạc sĩ này là cơng trình nghiên cứu của bản
thân tơi dưới sự hướng dẫn của PGS.TS Nguyễn Linh Giang.
• Các kết quả nêu trong Luận văn tốt nghiệp là trung thực, không phải là sao
chép tồn văn của bất kỳ cơng trình nào khác.
Hà Nội, ngày … tháng … năm 2019
Tác giả LVThS

Vũ Mạnh Cường

i

LỜI CẢM ƠN
Đầu tiên, tôi xin được gửi lời cảm ơn sâu sắc nhất tới Thầy giáo – PGS.TS
Nguyễn Linh Giang – trưởng bộ môn Truyền thông và Mạng máy tính, Viện Cơng
nghệ thơng tin và Truyền thơng, Trường Đại học Bách Khoa Hà Nội đã hướng dẫn
và cho tôi những lời khuyên trong quá trình thực hiện luận văn này.
Tiếp theo, tôi xin chân thành cảm ơn các thầy cô trong Viện Công nghệ thông
tin và truyền thông, Viện đào tạo sau đại học, Trường Đại học Bách Khoa Hà Nội
đã tạo điều kiện cho tôi trong suốt quá trình học tập và nghiên cứu tại trường.
Cuối cùng, tơi xin bày tỏ lòng cảm ơn tới những người thân trong gia đình,
bạn bè đã động viên và giúp đỡ để tơi hồn thành bản luận văn này.
Hà Nội, ngày … tháng … năm 2019
Tác giả LVThS

Vũ Mạnh Cường

ii


MỤC LỤC
LỜI CAM ĐOAN ....................................................................................................... i
LỜI CẢM ƠN ............................................................................................................ ii
MỤC LỤC ................................................................................................................. iii
DANH MỤC KÝ HIỆU, CÁC CHỮ VIẾT TẮT ..................................................... vi
DANH MỤC HÌNH ẢNH ....................................................................................... vii
MỞ ĐẦU .....................................................................................................................1
1.

Đặt vấn đề...................................................................................................1


2.

Phương pháp đề xuất ..................................................................................1

3.

Bố cục luận văn ..........................................................................................2

CHƯƠNG 1: GIỚI THIỆU CƠ CHẾ ĐĂNG NHẬP MỘT LẦN..............................3
1.1.

Tổng quan về Single sign-on......................................................................3

1.2.

Tổng quan về xác thực ...............................................................................4

1.2.1.

Các phương thức xác thực..........................................................................5

1.2.2.

Các giao thức xác thực ...............................................................................6

1.2.2.1. OpenID .......................................................................................................6
1.2.2.2. OAuth2 .......................................................................................................7
1.2.2.3. SAML .........................................................................................................9
1.3.


Nguyên lý hoạt động của Single sign-on .................................................11

1.4.

Một số giải pháp Single sign-on hiện nay ................................................12

1.4.1.

Facebook Connect ....................................................................................13

1.4.2.

Central Authentication Service ................................................................14

1.5.

Ưu điểm và nhược điểm ...........................................................................15

1.6.

Một số vấn đề thường gặp khi triển khai .................................................16

CHƯƠNG 2: TỔNG QUAN VỀ OAUTH2 .............................................................17
2.1.

Giới thiệu về OAuth2 ...............................................................................17

2.2.


Lịch sử phát triển......................................................................................17

2.3.

Nguyên lý hoạt động ................................................................................17

2.3.1.

Các đối tượng trong OAuth2 ....................................................................17

2.3.2.

Sơ đồ luồng hoạt động .............................................................................18

iii


2.3.3.

Đăng ký thông tin ứng dụng.....................................................................19

2.3.4.

ClientID và Client Secret .........................................................................19

2.3.5.

Cấp ủy quyền ( Authorization Grant).......................................................19

2.3.5.1. Cấp ủy quyền sử dụng mã ủy quyền (Authorization Code) .....................19

2.3.5.2. Cấp ủy quyền ngầm định (Implicit) .........................................................21
2.3.5.3. Cấp ủy quyền bằng password (Password) ................................................23
2.3.5.4. Cấp ủy quyền bằng thông tin ứng dụng (Client Credentials) ..................23
2.3.6.

Các hoạt động khác trong OAuth2 ...........................................................23

2.3.6.1. Sử dụng Access Token để lấy dữ liệu ......................................................23
2.3.6.2. Yêu cầu gửi access token mới ..................................................................23
2.3.7.

Ưu nhược điểm của OAuth2 ....................................................................24

CHƯƠNG 3: GIẢI PHÁP OAUTH2 VÀ ĐĂNG NHẬP MỘT LẦN ...........................25
3.1.

Giới thiệu mô hình ...................................................................................25

3.1.1.

Các giải pháp Single sign-on sử dụng OAuth2 hiện nay .........................25

3.1.1.1. Xây dựng Single sign-on với các nhà cung cấp Provider ........................25
3.1.1.2. Xây dựng Single sign-on với vai trò là nhà cung cấp Provider ...............26
3.1.2.

Hệ thống đăng nhập một lần sử dụng OAuth2 .........................................27

3.1.3.


Thực trạng và mơ hình truyền thống ........................................................27

3.1.4.

Nhu cầu và lợi ích của giải pháp ..............................................................27

3.1.5.

Lý do lựa chọn công nghệ ........................................................................28

3.1.6.

Giới thiệu về PHP, framework Laravel, laravel-passport ........................29

3.1.6.1. Giới thiệu về PHP ....................................................................................29
3.1.6.2. Giới thiệu về framework Laravel .............................................................31
3.1.6.3. Giới thiệu về Laravel-passport .................................................................33
3.2.

Quy mô của giải pháp ..............................................................................33

3.3.

Phạm vi của giải pháp ..............................................................................37

3.4.

Mục tiêu....................................................................................................39

3.5.


Phân tích và thiết kế hệ thống ..................................................................39

3.5.1.

Mơ tả bài tốn ...........................................................................................39

3.5.2.

Mơ hình hệ thống .....................................................................................40

3.5.2.1. Sơ đồ khối chức năng ...............................................................................40

iv


3.5.2.2. Sơ đồ hoạt động ........................................................................................41
3.6.

Ưu điểm, nhược điểm ...............................................................................42

3.7.

Môi trường và thử nghiệm .......................................................................43

3.7.1.

Môi trường ...............................................................................................43

3.7.2.


Thử nghiệm ..............................................................................................43

3.7.2.1. Cài đặt Laravel .........................................................................................43
3.7.2.2. Cài đặt Laravel-passport ..........................................................................44
3.7.2.3. Cài đặt laravel-client ................................................................................50
3.7.2.4. Cài đặt Redis ............................................................................................53
3.7.2.5. Cấu hình share storageSession trên mỗi sub domain ...............................53
3.7.2.6. Cấu hình Virtual Domain .........................................................................55
3.8.

Đánh giá hiệu quả hệ thống ......................................................................56

3.8.1.

Tạo Client ID, Client Secret .....................................................................56

3.8.2.

Thử nghiệm tính năng login với Single sign-on ......................................57

3.8.3.

Thử nghiệm tính năng logout với Single sign-on ....................................61

3.8.4.

Thử nghiệm tính năng access_token hết hạn ...........................................62

3.8.5. Thử nghiệm tính năng người dùng khơng cấp quyền truy cập .........63

3.8.6. Thử nghiệm tính năng người dùng xác thực khơng thành cơng .......65
3.8.7.

Thử nghiệm tính năng truy cập thơng tin người dùng .............................65

3.8.8.

Thử nghiệm tính năng bình luận trang tin tức..........................................67

3.8.9.

Kết luận ....................................................................................................70

3.9.

Đề xuất cải thiện .......................................................................................70

KẾT LUẬN ...............................................................................................................71
1.

Tổng kết....................................................................................................71

2.

Hướng phát triển ......................................................................................71

TÀI LIỆU THAM KHẢO .........................................................................................72

v



DANH MỤC KÝ HIỆU, CÁC CHỮ VIẾT TẮT
Từ viết tắt

Nghĩa tiếng Anh

Nghĩa tiếng Việt

SSO

Single sign-on

Hệ thống đăng nhập một lần

HA

High Availability

Tính sẵn sàng cao

ORM

Object Relational Mapping

PDO

PHP Data Object

API


Application Programming Interface

vi

Giao diện lập trình ứng dụng


DANH MỤC HÌNH ẢNH
Hình 1: Tổng quan về Single sign-on ..................................................................................... 3
Hình 2: Một số dịch vụ của Google ........................................................................................ 4
Hình 3: Phân loại các phương thức xác thực ............................................................................ 5
Hình 4: Cách thức hoạt động của OAuth2 ............................................................................... 8
Hình 5: Cách thức hoạt động của SAML .............................................................................. 10
Hình 6: Cách thức hoạt động của Single sign-on .................................................................... 11
Hình 7: Sơ đồ luồng hoạt động OAuth2 ................................................................................ 18
Hình 8: Sơ đồ hoạt động Authorization Code ........................................................................ 20
Hình 9: Ủy quyền Authorization Code.................................................................................. 20
Hình 10: Sơ đồ hoạt động Implicit ....................................................................................... 22
Hình 11: PHP được ưu chuộng làm nền tảng chính để thiết kế web[9] ....................................... 29
Hình 12: OOP giúp các lập trình viên tiếp cận, mở rộng ứng dụng[9] ........................................ 30
Hình 13: Sự tăng tưởng của Laravel trên Github[11] ................................................................ 31
Hình 14: Mơ hình MVC trong laravel[11] ............................................................................... 32
Hình 15: Mơ hình triển khai hệ thống lý tưởng ...................................................................... 34
Hình 16: Mơ hình HA của Application ................................................................................. 35
Hình 17: Mơ hình HA database ........................................................................................... 36
Hình 18: Mơ hình redis custer ............................................................................................. 36
Hình 19: Mơ hình triển khai hệ thống phạm vi demo .............................................................. 38
Hình 20: Sơ đồ khối chức năng hệ thống Single sign-on sử dụng OAuth2 ................................. 40
Hình 21: Sơ đồ hoạt động hệ thống Single sign-on sử dụng OAuth2 ........................................ 41
Hình 22: Cài đặt Laravel ..................................................................................................... 44

Hình 23: Cài đặt laravel-passport ......................................................................................... 44
Hình 24: Đăng ký Provider ................................................................................................. 45
Hình 25: Thêm trait cho User Model .................................................................................... 46
Hình 26: Đăng ký Passport routes ........................................................................................ 47
Hình 27: Thay đổi kiểu xác thực api ..................................................................................... 47
Hình 28: Đăng ký vue component ........................................................................................ 48
Hình 29: Trang chủ Auth Server .......................................................................................... 49
Hình 30: Thêm router cho Client ......................................................................................... 50
Hình 31: Thêm action cho Client ......................................................................................... 51
Hình 32: Thêm xử lí cho trang chủ ....................................................................................... 52
Hình 33: Trang chủ Hust Client B ........................................................................................ 52
Hình 34: Cài đặt redis......................................................................................................... 53
Hình 35: Cấu hình redis session ........................................................................................... 54
Hình 36: Cấu hình mơi trường share Session ......................................................................... 54
Hình 37: Cấu hình virtual Domain ....................................................................................... 55
Hình 38: Tạo ClientID , Client Secret ................................................................................... 56
Hình 39: Thơng tin ClientID , Client Secret .......................................................................... 57
Hình 40: Trang chủ Hust Client B ........................................................................................ 57
Hình 41: Đăng nhập hệ thống .............................................................................................. 58
Hình 42: Cấp quyền truy cập tài nguyên ............................................................................... 58
Hình 43: Xác thực tài khoản tại Hust Client B thành công....................................................... 59
Hình 44: Xác thực tài khoản tại Hust Client C thành cơng với SSO .......................................... 60
Hình 45: Đăng xuất thành cơng trên các website .................................................................... 61
Hình 46: Truy cập với access_token hết hạn.......................................................................... 62

vii


Hình 47: Trang chủ website b.devlocal.com .......................................................................... 64
Hình 48: Xác thực với thơng tin khơng đúng ......................................................................... 65

Hình 49: Thơng tin người dùng trước khi thay đổi ................................................................. 66
Hình 50: Thơng tin người dùng sau khi thay đổi .................................................................... 66
Hình 51: Trang tin tức ........................................................................................................ 67
Hình 52: Tính năng bình luận của người dùng đã đăng nhập ................................................... 68
Hình 53: Trang chi tiết tin tức khi người dùng chưa đăng nhập ................................................ 69

viii


MỞ ĐẦU
1. Đặt vấn đề
Trong thời gian gần đây với sự phát triển của nghành Công nghệ thông tin,
xu hướng các dịch vụ cùng nhau chia sẻ dữ liệu người dùng đang là hướng phát
triển chung. Thực tế một người dùng quản lí rất nhiều tài khoản, mật khẩu cho các
dịch vụ, ứng dụng mà họ tham gia. Việc người dùng quản lí các thơng tin tài khoản
và sử dụng sẽ nảy sinh các vấn đề khơng đảm bảo tính an ninh, an toàn và phát sinh
thêm những nghiệp vụ khác. Do vậy nhu cầu đăng nhập một lần – Single sign-on
cho các ứng dụng và dịch vụ này là cần thiết. Cơ chế Single sign-on (SSO) cho các
ứng dụng và dịch vụ này là cấp thiết.
Cơ chế SSO đảm bảo cho người dùng hợp pháp có thể truy cập và một hệ
thống hay nhiều hệ thống kết nối với nhau, chỉ phải sử dụng một tài khoản duy nhất.
SSO cho phép người dùng đăng nhập vào một hệ thống, họ sẽ đăng nhập vào tất cả
các hệ thống liên quan.
2. Phương pháp đề xuất
Với sự phát triển bùng nổ của nghành Công nghệ thông tin, các dịch vụ phát
triển mạnh. Nhu cầu đăng nhập một lần – Single sign-on là cấp thiết khi vấn đề về
bảo mật, dữ liệu cá nhân ngày càng được quan tâm. Người dùng được cấp quyền
truy cập hệ thống, nhưng cũng có thể bị thu hồi mọi quyền truy cập trái phép ở
tương lai và họ không cần cung cấp mật khẩu của họ. Người dùng được quyết định
việc cho phép cấp quyền truy cập vào dữ liệu cá nhân mỗi khi ứng dụng thứ 3 có

nhu cầu.
Có nhiều giao thức, giải pháp, kỹ thuật cho phép xây dựng hệ thống Single
sign-on. Các giải pháp này có những ưu điểm, nhược điểm, phù hợp với những nhu
cầu, nghiệp vụ riêng. Tuy vậy các giải pháp cũng đã giải quyết được bài toán xây
dựng hệ thống đăng nhập một lần.
Trong luận văn này, tôi tập trung nghiên cứu giao thức OAuth2, từ đó xây dựng
hệ thống Single sign-on cho các subdomain. Giải pháp là cơ sở giúp cho doanh nghiệp

1


có thể xây dựng các module, nghiệp vụ quản lí khách hàng tập trung, xử lí các vấn đề
sau bán hàng, chăm sóc khách hàng tốt, đưa ra chiến lược, kế hoạch kinh doanh phù
hợp là điều thực sự mang lại lợi ích cho cả doanh nghiệp lẫn khách hàng.
Đối tượng nghiên cứu của luận văn bao gồm: Cơ chế đăng nhập một lần, tập
trung đi sâu nghiên cứu giao thức OAuth2 , giải pháp chia sẻ phiên truy cập.
Để thực hiện được mục đích nghiên cứu nêu trên, phương pháp nghiên cứu
sử dụng trong luận văn là phương pháp nghiên cứu lý thuyết và kếp hợp với phương
pháp triển khai thực nghiệm. Để có thể làm được thì tác giả phải thu thập tài liệu từ
nhiều nguồn thông tin khác nhau bao gồm: Internet, sách báo và những người có
kinh nghiệm...
Trong các chương sau sẽ mơ tả về Single sign-on, cũng như giải pháp sử
dụng OAuth2 xây dựng hệ thống đăng nhập một lần.
3. Bố cục luận văn
Bố cục luận văn nội dung chính gồm 3 chương:
Chương 1: Giới thiệu thiệu về cơ chế đăng nhập một lần: Trình bày tổng
quan về xác thực, Single sign-on, nguyên lý hoạt động, một số giải pháp SSO hiện
nay.
Chương 2: Tổng quan về OAuth2 : Trình bày khái niệm, nguyên lý hoạt
động, ưu điểm, nhược điểm của giao thực OAuth2.

Chương 3: Giải pháp OAuth2 và đăng nhập một lần: Trình bày về các vấn
đề liên quan đến các giải pháp xây dựng hệ thống, phân tích thiết kế hệ thống, cài
đặt, triển khai hệ thống. Xây dựng các kịch bản thử nghiệm hệ thống.
Kết luận: Đưa ra được những kết quả đạt được trong luận văn và định hướng
phát triển tiếp cho giải pháp.
Phụ lục tài liệu tham khảo

2


CHƯƠNG 1: GIỚI THIỆU CƠ CHẾ ĐĂNG NHẬP MỘT LẦN
1.1. Tổng quan về Single sign-on
SSO là một cơ chế xác thực yêu cầu người dùng đăng nhập vào chỉ một lần
với một tài khoản và mật khẩu để truy cập vào nhiều hệ thống, ứng dụng trong 1
phiên làm việc.

Hình 1: Tổng quan về Single sign-on
Trước khi có SSO, để truy cập vào ứng dụng, hệ thống người dùng phải nhập
tài khoản và mật khẩu. Điều này khiến trải nghiệm người dùng không tốt, tốn thời
gian, tăng nguy cơ mất bảo mật… Do đó hệ thống, website có sử dụng SSO sẽ đem
lại nhiều thuận tiện cho người dùng, tăng tính bảo mật.
Ví dụ: Với các dịch vụ của Google cung cấp: Gmail, Youtube, Drive, Scholar,
CHPlay.. người dùng phải nhập thông tin tài khoản của dịch vụ để xác thực khi
muốn truy cập, sử dụng. Với SSO người dùng chỉ cần sử dụng 1 tài khoản Google

3


để có thể đăng nhập và sử dụng tất cả các dịch vụ, ứng dụng của google. Điều đó
thực sự mang lại trải nghiệm tốt cho người dùng.


Hình 2: Một số dịch vụ của Google
Đăng nhập là quá trình người dùng sử dụng định danh và các thông tin bảo
mật khác để kết nối bảo mật với hệ thống. Quá trình đăng nhập gồm 2 bước Xác
thực và Ủy quyền:
Xác thực ( Authentication): Xác thực người dùng có hợp lệ không thông qua
các phương thức xác thực của hệ thống như: username/password, thẻ từ, faceId…
Ủy quyền ( Authorization): Là quá trình kiểm tra sau khi người dùng đã được
xác thực có quyền truy cập vào tài ngun hay khơng?

1.2. Tổng quan về xác thực
Xác thực (Authentication) là một hành động nhằm chứng thực một người, đối
tượng nào đó. Xác thực cho phép xác định người dùng hiện tại là ai, họ có mặt hay
khơng? Một giao thức xác thực đầy đủ có thể sẽ có các thơng tin định danh về
người dùng : mã định danh duy nhất người dùng (ID), tên người dùng, ngày sinh,
email…

4


1.2.1. Các phương thức xác thực
Các phương pháp xác thực có thể chia thành 3 loại dựa theo các đặc điểm của
chúng [13]

Hình 3: Phân loại các phương thức xác thực
Xác thực theo tri thức
Đây là phương thức sử dụng thông dụng nhất hiện nay. Phương thức sử dụng
mật khẩu bằng các chuỗi ký tự, hình ảnh, nhận dạng khn mặt hay sử dụng mã số
cá nhân (PINs). Đối với mạng Internet không đảm bảo về an ninh, để xác thực
thường sử dụng Digital Certificates and Digital Signatures.

Xác thực theo sự sở hữu
Xác thực theo sự sở hữu dựa vào những gì mà người dùng có (các đối tượng vật
lý như: Thẻ…). Tuy nhiên nhược điểm của phương thức này là thẻ khơng chứng
minh được quyền sở hữu vì nó có thể dễ dàng bị đánh cắp hoặc sao chép. Vì vậy
việc sử dụng phương pháp này đi kèm mã PIN sẽ bảo mật hơn nhiều so với việc
dùng thẻ hay mã PIN đơn lẻ.

5


Xác thực theo sinh trắc học
Đây là phương thức xác thực dựa trên các đặc điểm sinh lý, hành vi của người
dùng, đó là các đặc điểm vật lý đã được chứng minh là có thể xác thực: Vân tay,
võng mạc, khn mặt, giọng nói, loại máu…
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 chia sẻ. Tuy nhiện phương thức này không được sử dụng phổ biến và chủ
yếu được sử dụng trong các hệ thống quan trọng, nơi yêu cầu độ bảo mật cao vì:
-

Tốn kém về chi phí phần cứng, phần mềm chuyên dụng

-

Xâm phạm về quyền riêng tư.

-

Nguy cơ về bảo mật khi thơng tin có thể bị phân tích, đánh cắp làm cho việc
xác thực khơng cịn đáng tin cậy


1.2.2. Các giao thức xác thực
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 đối
tượng. Hiện nay có rất nhiều các giao thức xác thực được sử dụng (Pap, Chap,
Radius, Kerberos, Open Id, OAuth2, Saml2…), tuy nhiên phổ biến hiện nay là giao
thức: OAuth2, Open Id, Saml2 vì chúng tuân theo chuẩn chung và có nhiều ưu
điểm.

1.2.2.1. OpenID
Khái niệm
OpenID là một chuẩn mở cho xác thực (Authentication ). Được phát triển bởi tổ
chức phi lợi nhuận OpenID Foundation, OpenID cho phép người dùng có thể được
xác thực bởi rất nhiều website ( Relying Parties hoặc RP) sử dụng dịch vụ của bên
thứ 3. Nó giảm được việc phải thiết lập riêng logic signup/login cho mỗi website,
cho phép các người dùng có thể đăng nhập tới nhiều webstie ko hề liên quan tới
nhau mà ko cần phải có những định danh và password riêng cho mỗi website [6].
Phiên bản mới nhất của OpenID là OpenID Connect

6


Cách thức hoạt động
Các thành phần chính:
- Relying Party (RP): Là một trang web hay ứng dụng muốn xác nhận người dùng.
- OpenID Provider: Chịu trách nhiệm phát hành Identifers và thực hiện xác
thực người dùng.
Khi Website A sử dụng OpenID để xác thực người dùng quy trình được diễn
ra theo các bước như sau:
+ Website A chuyển tiếp người dùng về một URL của OpenID Provider để
đăng nhập.
+ Nếu đăng nhập thành công OpenID Provider sẽ chuyển tiếp người dùng về

RP, kèm thông tin người dùng đã xác thực.
+ Website A thực hiện xác thực người dùng mà không cần phải thực hiện đăng
nhập vì tin tưởng kết quả trả về của OpenId Provider

1.2.2.2. OAuth2
Khái niệm
OAuth2 là một chuẩn mở để ủy quyền/phân quyền (authorization), OAuth2
cũng là nền tảng của OpenID Connect, nó cung cấp OpenID (xác thực authentication) ở phía trên của OAuth2 (ủy quyền - authorization) để có một giải
pháp bảo mật hồn chỉnh hơn. OpenID Connect (OIDC) được tạo ra vào đầu năm
2014 và OAuth2 hoàn tồn độc lập, chứ khơng phải một phần của OIDC.
OAuth2 cung cấp quyền truy cập đã được ủy quyền an tồn (secure delegated
access), điều đó có nghĩa là một ứng dụng hay một client có thể thao tác hoặc truy
cập các tài nguyên trên một server thay mặt cho một người dùng, mà không cần
người sử dụng phải chia sẻ thông tin tài khoản của họ với ứng dụng. OAuth2 làm
điều này bằng các token được tạo ra bởi một nhà cung cấp nhận dạng (Identity
Provider) cho các ứng dụng bên thứ ba, với sự chấp thuận của người dùng [2].

7


Cách thức hoạt động
Các thành phần chính
- Resource Owner: Một thực thể có khả năng cấp quyền truy cập vào một tài
nguyên được bảo vệ. Khi chủ sở hữu tài nguyên là một người, nó được gọi là người
dùng cuối.
- Resource Server: Máy chủ lưu trữ các tài nguyên được bảo vệ, có khả năng
chấp nhận và đáp ứng các yêu cầu tài nguyên được bảo vệ bằng access_token.
- Client (Application): Một ứng dụng yêu cầu tài nguyên được bảo vệ thay mặt
cho resource owner và với sự chứng thực của tài nguyên đó.
- Authorization Server : Máy chủ phát hành access token cho client sau khi xác

thực thành công resource owner và nhận được ủy quyền.

Hình 4: Cách thức hoạt động của OAuth2
Quy trình hoạt động diễn ra như sau:
1.Application yêu cầu ủy quyền để truy cập vào Resource Server thông qua User
2. Nếu User ủy quyền cho yêu cầu trên, Application sẽ nhận được giấy ủy
quyền từ phía User (dưới dạng một token string nào đó chẳng hạn)

8


3. Application gửi thơng tin định danh (ID) của mình kèm theo giấy ủy quyền
của User tới Authorization Server.
4. Nếu thông tin định danh được xác thực và giấy ủy quyền hợp lệ,
Authorization Server sẽ trả về cho Application access_token. Đến đây q trình
ủy quyền hồn tất.
5. Để truy cập vào tài nguyên (resource) từ Resource Server và lấy thông tin,
Application sẽ phải đưa ra access_token để xác thực.
6. Nếu access_token hợp lệ, Resource Server sẽ trả về dữ liệu của tài nguyên
đã được yêu cầu cho Application.

1.2.2.3. SAML
Khái niệm
SAML (Security Assertion Markup Language) là “chuẩn mở “ cho phép nhà
cung cấp nhận dạng (Identity Provider) xác thực người dùng và ủy quyền cho người
dùng sử dụng một dịch vụ nào đó của nhà cung cấp dịch vụ (Service Provider - SP)
mà không bắt buộc người dùng phải tạo tài khoản đăng nhập vào dịch vụ đó[4].
Cách thức hoạt động
Các thành phần chính [4]
- Identity Provider (IdP): Nhà cung cấp nhận dạng.

- Service Provider (SP): Nhà cung cấp dịch vụ.
- SP Private Key: Được thống nhất, trao đổi trước giữa SP và IdP bằng cách
nào đó.

9


Hình 5: Cách thức hoạt động của SAML
Bước 1: Người dùng thực hiện 1 yêu cầu login tới Service Provider.
Bước 2: Phía SP sẽ tạo ra một SAML Request để gửi tới IdP, SAML Request
này sẽ được chính SP ký điện tử (sign) bằng chữ ký của SP (chữ ký của SP ở đây
chính là khóa bí mật của SP).
Bước 3: Phía IdP khi nhận được SAML Request từ SP sẽ phải xác thực chữ ký
có đúng là của SP hay khơng bằng cách dùng khóa private (SP private key) của SP
để xác thực.
Bước 4: Vẫn đang ở IdP, sau khi xác thực được chữ ký của SP rồi, IdP sẽ làm
những thứ sau:
+ Lấy ra thông tin người dùng đang sử dụng browser (nếu người dùng đang
đăng nhập vào IdP, cịn nếu người dùng đang khơng đăng nhập thì bắt người dùng
đăng nhập trước) để redirect (http post) về cho SP sử dụng (kết quả trả về này gọi là
SAML Response). Trước khi gửi về cho SP thì IdP sẽ ký điện tử (sign) vào SAML
Response bằng khóa bí mật của IdP.
+ Không những IdP ký vào SAML Response mà IdP cũng sẽ mã hóa các kết quả
dữ liệu (SAML Assertions) có trong SAML Response bằng khóa cơng khai của SP.
Bước 5: Khi SP nhận được SAML Response, nó sẽ thực hiện những việc sau:
+ Dùng khóa cơng khai của IdP để xác thực xem có đúng là kết quả được gửi
từ IdP hay khơng (đây chính là phần xác thực mà OAuth và OAuth2 khơng có).

10



Khóa cơng khai của IdP cũng giống như nói ở trên, có thể lấy thơng qua metadata
url của IdP hoặc có thể được trao đổi trước.
+ Nếu xác thực đúng chữ ký, SP sẽ tiếp tục dùng khóa cơng khai của chính
mình để giải mãi SAML Assertions đã được mã hóa từ phía IdP.
+ Lấy các thơng tin dữ liệu người dùng trong SAML Assertions để đăng nhập
người dùng vào hệ thống của chính mình, và trả về cho người dùng thông báo thành
công (hay điều hướng người dùng tới các tài nguyên mong muốn)

1.3. Nguyên lý hoạt động của Single sign-on
Mơ hình ngun lý hoạt động của Single sign-on [3]

Hình 6: Cách thức hoạt động của Single sign-on
1. Người dùng lần đầu truy cập domain1.
2. Domain1 redirect về trang login AuthServer để xác thực người dùng.
3. AuthServer thực hiện xác thực với thông tin nhận được từ trang login.
4. AuthServer thực hiện save cookie với thông tin xác thực của domain1.
5. AuthServer send token và redirect về domain1.
6. Domain1 xác thực với token nhận được cho phép người dùng truy cập hệ thống.

11


7. Domain1 thực hiện lưu trữ cookie với thông tin token xác thực nhận được.
8. Người dùng lần đầu truy cập domain2.
9. Domain2 redirect về trang login AuthServer để xác thực người dùng.
10. AuthServer get thông tin từ cookie ở bước 4 để kiểm tra xác thực.
11. AuthServer send token và redirect về domain2.
12. Domain2 xác thực với token nhận được cho phép người dùng truy cập hệ thống
13. Domain2 thực hiện lưu trữ cookie với thông tin token xác thực nhận được.


1.4. Một số giải pháp Single sign-on hiện nay
Một số giải pháp Single sign-on hiện nay[12].
- CAS / Central Authentication Service:
o Nhà phát triển: Apereo
o Loại hình: Free & Open Source (Apache 2.0)
o Mô tả: Protocol and open-source SSO server/client implementation with
support for CAS, SAML1, SAML2, OAuth2, SCIM, OpenID Connect and WS-Fed
protocols both as an identity provider and a service provider with other auxiliary
functions that deal with user consent, access management, impersonation, terms of
use, etc. Licensed under Apache 2.0.
- Active Directory Federation Services:
o Nhà phát triển: Microsoft
o Loại hình: Proprietary
o Mơ tả: Claims-based system and application federation
- Facebook connect
o Nhà phát triển: Facebook
o Loại hình: Proprietary
o Mơ tả: Facebook SSO to third parties enabled by Facebook
- Keycloak (Red Hat Single Sign-On):
o Nhà phát triển: Red Hat
o Loại hình: Open source
o Nền tảng: Có

12


o Mô tả: Federated SSO (LDAP and Active Directory), standard protocols
(OpenID Connect, OAuth 2.0 and SAML 2.0) for Web, clustering and single sign
on. Red Hat Single Sign-On is version of Keycloak for which RedHat provides

commercial support.
- myOneLogin
o Nhà phát triển: Vmware
o Loại hình: Proprietary
o Mơ tả: Cloud single sign-on
- OneLogin:
o Nhà phát triển: OneLogin Inc.
o Loại hình: Proprietary
o Nền tảng: Có
o Mơ tả: Cloud-based identity and access management with single sign-on
(SSO) and active directory integration
- WSO2 Identity Server:
o Nhà phát triển WSO2.
o Loại hình: Free & Open Source (Apache 2.0)
o Nền tảng: Có
o Mơ tả: SAML 2.0, OpenID, OpenID Connect, OAuth 2.0, SCIM, XACML,
Passive Federation
Để có thể triển khai Single sign-on có rất nhiều giải pháp từ các giải pháp mở,
giải pháp đóng. Tuy nhiên các giải pháp đều có những ưu điểm, nhược điểm, phù
hợp với những nhu cầu, nghiệp vụ riêng.

1.4.1. Facebook Connect
Facebook Connect là một Closesource cung cấp giải pháp Single sign-on của
Facebook được ra đời vào 12/2008. Giải pháp cho phép người dùng đăng nhập vào
các trang web, ứng dụng hoặc thiết bị của bên thứ 3 bằng cách sử dụng tài khoản
facebook.

13



Khi người dùng cho phép, ứng dụng 3rd được phép truy cập thơng tin cá nhân
trên facebook: Họ tên, hình ảnh, bài viết, thông tin bạn bè…
Ưu điểm
- Giải pháp có độ an tồn, bảo mật cao vì được phát triển bởi Facebook
- Với việc Client hỗ trợ các thư viện đa nền tảng (Android, Web…), đa ngôn
ngữ (Java, PHP, JS…) khiến cho việc tích hợp với hệ thống Facebook nhanh chóng
và đơn giản.
- Cộng đồng người sử dụng đơng đảo (2,234 tỷ người dùng tính đến hết quý
1/2018).
- Giải pháp phù hợp với mục tiêu tích hợp Single sign-on cho những hệ thống
muốn giảm bớt các nghiệp vụ liên quan đến người dùng, mong muốn có một giải
pháp bảo mật, đem lại sự trải nghiệm cao.
Nhược điểm
- Facebook Connect là một giải pháp Single sign-on tốt được phát triển bởi
Facebook. Tuy nhiên do là một Closesource, chỉ cung cấp giải pháp tích hợp cho
3rd khiến cho việc mở rộng hệ thống khá là khó khăn. Sự phụ thuộc hồn tồn vào
giải pháp, chính sách của Facebook cũng là một rào cản lớn. Do vậy Facebook
Connect không phải là một sự lựa chọn hàng đầu với mục tiêu xây dựng, phát triển
một hệ thống Single sign-on cả 2 phía Server và Client

1.4.2. Central Authentication Service
Central Authentication Service (CAS) là một Opensource cung cấp giải pháp
Single sign-on được phát triển bởi đại học Yale từ 12/2004. Giao thức CAS bao
gồm ít nhất 3 bên: Trình duyệt Web của Client, các ứng dụng Web yêu cầu chứng
thực, máy chủ CAS.
Ưu điểm
- Giải pháp OpenSource được cộng đồng sử dụng đông đảo, mạnh mẽ, tài liệu
phong phú.
- Là một giải pháp tốt với sự hỗ trợ các thư viện đa ngôn ngữ ( PHP, .NET,
JAVA, RUBY…), hỗ trợ đa giao thức (CAS, SAML1, SAML2, OAuth2, SCIM,


14


OpenID Connect…) khiến cho việc xây dựng hệ thống cả 2 phía Client và Server có
nhiều sự lựa chọn
Nhược điểm
- Chi phí để xây dựng hệ thống Single sign-on với giải pháp CAS cao do được
viết bởi ngôn ngữ Java.
- Việc phát triển ở Client phụ thuộc vào thư viện được cung cấp do vậy khiến
cho việc cập nhật, phát triển khá là khó khăn. Việc cập nhật nghiệp vụ, thư viện cho
toàn bộ các Client kết nối mỗi khi muốn scale hệ thống khá là khó khăn và có chi
phí cao. Vì vậy giải pháp khơng phù hợp với những hệ thống nặng về nghiệp vụ,
việc cập nhật, bổ sung nghiệp vụ diễn ra thường xuyên.

1.5. Ưu điểm và nhược điểm
Ưu điểm
- Tăng trải nghiệm người dùng khi sử dụng dịch vụ.
- Hệ thống SSO cung cấp cho người dùng 1 giải pháp xác thực đăng nhập một
lần. Khi đăng nhập vào các hệ thống SSO, người dùng có thể dễ dàng truy cập vào
các hệ thống trong cùng một hệ sinh thái mà không cần phải xác thực lại trong
khoảng thời gian nhất định, tùy thuộc vào chính sách của nhà cung cấp hệ thống
SSO.
- Giúp cho các nhà phát triển dịch vụ giảm bớt nghiệp vụ liên quan đến xác
thực, quản lí người dùng. Tập trung vào các nghiệp vụ chính của dịch vụ.
- Tạo nên sự đồng bộ thông tin giữa các dịch vụ, ứng dụng trong 1 hệ sinh
thái.
- Tăng khả năng bảo mật thông qua việc giúp người dùng không cần nhớ
nhiều thông tin đăng nhập (định danh, mật khẩu ). Hạn chế sử dụng thông tin đăng
nhập bằng các sử dụng access_token để xác thực ở các hệ thống liên quan.

- Tiết kiệm thời gian cho người sử dụng trong việc đăng nhập vào nhiều dịch
vụ được cung cấp trên các nền tảng khác nhau.

15


- Là một giải pháp xác thực đơn giản, hiệu quả, chi phí thấp so với các
phương pháp xác thực theo tri thức, sở hữu, sinh trắc học. Phù hợp với các hệ
thống không yêu cầu bảo mật quá cao
Nhược điểm
- Chi phí triển khai một hệ thống SSO tốn kém cả về nhân lực, nguồn lực,
kinh phí, cần phải có sự tính tốn cẩn thận trước khi triển khai
- Khi đã được xác thực người dùng có thể truy cập vào các dịch vụ trong hệ
thống mà không cần xác thực lại. Do đó, nếu khơng được thiết kế, bảo mật tốt có
thể dẫn đến việc bị tấn cơng toàn hệ thống.

1.6. Một số vấn đề thường gặp khi triển khai
Triển khai SSO chỉ phù hợp với các doanh nghiệp có hệ sinh thái lớn, nguồn
nhân lực lớn, tập khách hàng nhiều. Lợi ích của việc triển khai SSO là đem lại trải
nghiệm tốt cho người dùng, giúp doanh nghiệp dễ dàng triển khai hệ thống theo mơ
hình microservice.
Nó thực sự có ý nghĩa với doanh nghiệp nếu có nhu cầu triển khai dịch vụ theo
mơ hình microservice, có một tập khách hàng lớn thường xuyên tương tác với hệ
thống. Có nhu cầu sử dụng thơng tin được sinh ra khi khách hàng tương tác cho các
vấn đề về chăm sóc khách hàng, đưa ra các chiến lược, kế hoạch kinh doanh phù
hợp… với sự hỗ trợ của Artificial Intelligence, Machine Learning… là điều thực sự
đem lại lợi ích cho cả doanh nghiệp và khách hàng.
SSO là con dao hai lưỡi, SSO bản thân nó khơng tự cải thiện vấn đề bảo mật
và trên thực tế nếu triển khai hệ thống không đúng cách, tuân thủ chặt chẽ các quy
định có thể làm giảm khả năng bảo mật của hệ thống dẫn đến có thể bị tin tặc tấn

cơng. Điều này thực sự là rủi ro lớn khi các dịch vụ trong hệ sinh thái có thể khơng
được triển khai, giám sát cùng một quy trình, nhân sự khơng tương đồng, và giải
pháp không được áp dụng nghiêm ngặt.

16