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

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

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 ễ

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ướ ự hưới s 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 toà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

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 đạ ọc, Trường Đạ ọi h 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 hoà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

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 ẾT TẮT vi  ỮVIDANH 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ố ấn đề thườ v 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

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 u 23 ữliệ 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ế ệ thố h ng 39

3.5.1 Mô tả bài toán 39

3.5.2 Mô hình hệ thống 40

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

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- 61 on 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Ả

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

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ườ dùng đăng nhậi 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

vi c cho phép c p quy n truy c p vào d u cá nhân m i khi ng d ng th 3 có ệ ấ ề ậ ữliệ ỗ ứ ụ ứ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

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

độ , ưu điể ng 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 ệ ả

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

để 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 nguyên 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…

Đâ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 khuôn 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 Cử ụ ertificates 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ẻ

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, khuôn 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 thiết lập riêng logic signup/login cho mỗi website, ải 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

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 hoàn chỉnh hơn OpenID Connect (OIDC) được tạo ra vào đầu năm

2014 và OAuth2 hoàn toà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 toà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]

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) ạ

3.Application ửi thông tin đị g nh danh (ID) c a mình kèm theo giủ ấy ủy quy n ề

của User ới Authorization Server t

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 v ẽ trả ề cho Application access_token Đến đây quá trình

ủy quy n hoà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 ẽ trả ề ữ liệ ủ s v d 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 đó

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 ằ ủ

+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ó) ự

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 p t c dùng khóa công khai c a chính ẽ tiế ụ ủ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 nguyên 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

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 i pháp Single sign-on hi n nay ộ ố giả ệ

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 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ó ề ả

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

Để 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

Khi người dùng cho phép, ng d ng 3ứ ụ rd đượ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 toà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

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 ộ ỉ ấ ả ợ

3 khi n cho vi c m r ng h rd ế ệ ở ộ ệ thống khá là khó khăn Sự ph ụ thuộc hoàn toà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

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

việc cập nh t, b sung nghi p v diậ ổ ệ ụ ễn ra thường xuyên

1.5 Ưu điể và nhược điể m 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 ấ ề ả

- 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 ầ ả ậ

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

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

2.1 Giớ i thi u v OAuth2 ệ ề

OAuth2 là m t chu n m ộ ẩ ở để chứng th c (Authentication) , y quy n/phân ự ủ ềquy n (authorization) nh ề ờ đó ứng d ng bên th 3 có th ụ ứ ể đại ện cho ngườdi i dùng truy cập vào tài nguyên người dùng n m trong mằ ột dịch vụ nào đó

OAuth2 = Open + Auth ( Authentication: xác thực người dùng thông qua việc đăng nhập, Authorization: c p quy n truy c p vào các Resource) ấ ề ậ [1]

2.2 L ch s phát tri n ị ử ể

- Tháng 11/2006, Twitter đưa ra chuẩn OAuth đầu tiên có tên là OpenID, điểm

yếu đó là yêu cầu người dùng ph i cung c p thông tin cá nhân (username + ả ấpassword)

- Tháng 4/2010, phát hành phiên b n chính thả ức đầu tiên c a Oauth 1.0 (RFC ủ5849) Sau đó lỗ ải b o m t nghiêm trậ ọng được phát hi n v i tên g i Session Fixation ệ ớ ọcho phép Hacker chiếm quyền truy c p vào tài nguyên c a ngư i dùng ậ ủ ờ

- Tháng 10/2012, OAuth2 ra đời, tuy v n còn nh ng l i b o mẫ ữ ỗ ả ật như dùng Chrome để Hack Facebook nhưng hiện vẫn đang đượ ử ục s d ng khá r ng rãi ộ

2.3 Nguyên lý hoạt động

OAuth2 gồm 4 đ i tưố ợng chính mang nh ng vai trò riêng : ữ

- Resource Owner : Là ch s h u d u, y quy n cho ng d ng cho phép ủ ở ữ ữ liệ ủ ề ứ ụtruy c p tài kho n c a mình v i nhậ ả ủ ớ ững scope được c p phép (vd: Ch ấ ỉcho phép l y ấthông tin cá nhân)

- Client: Là ứng d ng , website bên th ụ ứ 3 Trước khi được phép tương tác với

d ữliệu người dùng, ng d ng phứ ụ ải được sự ủ y quy n cề ủa người dùng

- Resource Server : Máy chủ tài nguyên, dữ liệu, nơi lưu trữ thông tin người dùng

- Authorization Server : Máy ch y quy n, có nhi m v xác thỉ ủ ề ệ ụ ực người dùng,

c p quy n cho c p cho Client thông qua access_token ấ ề ậ

2.3.2 Sơ đồ luồ ng ho ạt độ ng

Sơ đồ ồ lu ng hoạt động c a OAuth2 mô t ủ ả tương tác giữa 4 đối tượng bao g m ồcác bước sau [5]

Hình 7 : Sơ đồ luồ ng ho ạ ộ t đ ng OAuth2

A.Client yêu c u y quyầ ủ ền để truy c p vào ậ Resource Server thông qua Resource Owner

B Nếu Resource Owner y quyủ ền cho yêu cầu trên, Client sẽ ận đượ nh c giấy

ủy quy n tề ừ phía Resource Owner (dưới dạng một token string nào đó chẳng h n) ạ

C Client ửi thông tin đị g nh danh (ID) c a mình kèm theo gi y y quy n củ ấ ủ ề ủa Resource Owner t i Authorization Server ớ

D 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 Client access_token Đến đây quá trình ủy quyền hoàn t ất

E truy c p vào tài nguyên (resource) t Để ậ ừResource Server và l y thông tin, ấClient s ẽphải đưa ra access_token để xác thực

F N u access_token h p l , ế ợ ệ Resource Server ẽ trả ề ữ liệ ủ s v d u c a tài nguyên

đã được yêu c u cho ầ Client

2.3.3 Đăng ký thông tin ứ ng d ụ ng

Trước khi tích h p OAuth2 c a m t d ch v ợ ủ ộ ị ụ được cung c p (Facebook, ấGithub, Google) trong ứng d ng C n phụ ầ ải đăng ký ứng d ng v i d ch v ụ ớ ị ụ đó với các thông tin chính:

Application name: Tên ứng d ng ụ

Applcation website: Trang web ứng d ng ụ

Redirect URL hay Callback URL: Đường d n c a ng dẫ ủ ứ ụng để nh n k t qu ậ ế ảkhi quá trình y quy n hoàn t t, nhủ ề ấ ận các thông tin như mã ủy quy n, access_token ề

2.3.4 ClientID và Client Secret

Sau khi đăng ký ứng d ng v i d ch v , ClientID và Client Secret s ụ ớ ị ụ ẽ đượ ạc t o

ra bởi dịch v ụ

Client Id: Là một chu i ký t , dỗ ự ùng để nh n di n ng d ng bậ ệ ứ ụ ởi dịch v ụ

Client Secret: Là mã bí mật dùng để xác th c Client ID cự ủa ứng dụng

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

Trong sơ đồ ồ lu ng hoạt động OAuth2, y quy n (Authorization Grantủ ề ) được

s d ng bử ụ ởi ứng dụng để ấ l y access_token V i access_token ng dớ ứ ụng được c p ấphép để ấy đượ l c tài nguyên c a ngư i dùng ủ ờ

Các d ng y quy n ph ạ ủ ề ụ thuộc vào cách thức ứng d ng yêu c u xác th c và ụ ầ ự

d ng y quyạ ủ ền được hỗ trợ ở b i máy ch y quy n (Authorization server)ủ ủ ề

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

Đây là hình thứ ủc y quy n ph bi n nh t ề ổ ế ấ hay đượ ử ục s d ng hi n nay ệ [1]

Hình 8 : Sơ đồ ho ạ ộ t đ ng Authorization Code

0.Người dùng truy c p ng d ng ậ ứ ụ

1.Yêu cầu authorization_code

Application gửi User link đến nơi để ắt đầ b u quá trình nh n authorization_code ậ

https://OAUTH_SERVER.DOMAIN/oauth/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

2.User y quy n cho Application ủ ề

Khi User truy c p vào link, nh p thông tin xác thậ ậ ực người dùng Sau khi xác

thực xong, User sẽ được h i có cho phép/ t chỏ ừ ối Application truy c p thông tin ậ

của mình không?

Hình 9 : Ủ y quy n Authorization Code ề

3.Application nh n authorization_code ậ

N u User cho phép Application truy c p vào thông tin cá nhân, Auth Server s ế ậ ẽchuyển hướng người dùng đến ApplicationRedirectURL ( đã đăng ký ở bước 2.3.3)

Tại đây Application s lưu lại authorizatioẽ n_code

https://APPLICATION.DOMAIN/callback?code=AUTHORIZATION_CODE

4.Application yêu c u access_token ầ

Sau khi nhận được authorization_code Application c n th c hi n request lên ầ ự ệ

Auth Server để ấ l y access_token

https://OAUTH_SERVER.DOMAIN/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL

5.Application nh n access_token ậ

N u quá trình y quy n (authorization) thành công Auth Server s ế ủ ề ẽ chuyển hướng người dùng v redirectURL kèm theo access_token ề

https://APPLICATION.DOMAIN/callback#token=ACCESS_TOKEN

Lúc này Application đã được User y quy n truy c p Application có th s ủ ề ậ ể ử

dụng access_token để truy c p tài nguyên c a d ch v ậ ủ ị ụ đã được User cho phép cho

tới khi access_token hết hạ ử ụn s d ng

2.3.5.2 C ấ p ủ y quy n ng ề ầm đị nh (Implicit)

Loại ủy quyền này thường được s d ng cho các ng dử ụ ứ ụng di động hay các

ứng d ng ch y trên trình duy t ( vd: FireFox Extension) Vì lí do không th b o m t ụ ạ ệ ể ả ậđược thông tin authorization_code t i Client Lo i y quy n này không th c hi n ạ ạ ủ ề ự ệxác thực ID của Application, không c n phầ ải trao đổi authorization_code [1]

Implicit không hỗ trợ refesh_token

Hình 10 : Sơ đồ ho ạt độ ng Implicit

1.Implicit Authorization Link

Tương tự Authorization Code, User được đưa tới một link để yêu c u ầaccess_token từ Auth Server (v i response_type là token) ớ

https://OAUTH_SERVER.DOMAIN/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

2.User y quy n cho Application ủ ề

(Tương tự bước 2 c a Authorization Code) ủ

3.Browser nh n access_token thông qua redirect URI ậ

Sau khi User c p phép cho Application Auth Server s ấ ẽ chuyển hướng v ềredirect URI ( đã đăng ký ở bước 2.3.3)

https://APPLICATION.DOMAIN/callback#token=ACCESS_TOKEN

4.Browser duy trì access_token

Sau khi Browser được chuyển hướng v redirect URI nhiề , ệm v c a broser là ụ ủduy trì access_token và điều hướng quay tr lở ại ứng d ng ụ

Thông tin access_token trích xu t ấ ở bước 5 được đính kèm khi điều hướng quay tr lở ại Application.

Lúc này quá trình quá trình xác thực, ủy quy n hoàn t t ề ấ

2.3.5.3 C ấ p ủ y quy n b ng password (Password) ề ằ

Loại ủy quyền này được s d ng cho nhử ụ ững ứng dụng được tin tưởng b i Auth ởServer Lúc này User phải cung c p username, password trấ ực tiếp cho Application để lấy access_token Quá trình diễn ra hết sức đơn giản và nhanh chóng [1]

https://OAUTH_SERVER.DOMAIN/token?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID

2.3.5.4 C ấ p ủ y quy n b ng thông tin ng d ng (Client Credentials) ề ằ ứ ụ

Loại ủy quyền này được s d ng cho vi c truy c p vào chính thông tin tài ử ụ ệ ậkho n c a Application t i d ch v l y thông tin c a Application hay c p nhả ủ ạ ị ụ để ấ ủ ậ ật thông tin ( description, redirect_uri…) Tại đây không có sựtham gia của User[1]

https://OAUTH_SERVER.DOMAIN/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

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

Sau khi có được thông tin access_token, ng d ng có th truy c p tài nguyên ứ ụ ể ậ

của người dùng thông qua các request POST được mô t trong tài liả ệu đính kèm của bên cung c p dấ ịch vụ Yêu c u có dầ ạng như sau:

https://API_SERVER.DOMAIN/v2/$OBJECT

Với request header:

Accept: application/json

Authorization: Bearer ACCESS_TOKEN

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

Mỗi access_token thường có th i gian s ng nhờ ố ất định Khi truy c p tài nguyên ậ

n u access_token h t h n Appplication s nhế ế ạ ẽ ận được mã lỗi “Invalid Token Error” Lúc này application ph i g i m t yêu cả ử ộ ầu đến Auth Server để thực hi n l y ệ ấaccess_token mới dướ ại d ng POST request [1]

https://OAUTH_SERVER.DOMAIN/oauth/token?grant_type=refresh_token&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&refresh_token=REFRESH_TOKEN

Ưu điểm

- OAuth2 là m t giao th c d a trên TSL (ộ ứ ự Transport Layer Security) vì v y nó ậ

rất an toàn để lưu access_token của ngườ i dùng

- Cho phép truy c p h n ch vào d u cậ ạ ế ữliệ ủa người dùng

- OAuth thay th mô hình ch ng chia s m t kh u b ng giao thế ố ẻ ậ ẩ ằ ức ủy quy n ề

đồng thời an toàn hơn và dễ ử ụng hơn s d D dàng th c hi n và cung c p chu n xác ễ ự ệ ấ ẩthực mạnh m ẽ

- OAuth2 là chuẩn giao thức được sử ụ d ng r ng rãi và ph bi n nh t [8] ộ ổ ế ấ

Nhược điểm

- OAuth2 c n phầ ải được xây d ng c 2 phía server và client, ngoài ra OAuth2 ự ảtách authorization server và resource server ra cũng khiến cho vi c xây d ng m t ệ ự ấnhi u công s c ề ứ

- Nguy cơ bị ấ t n công di n r ng khi Auth Server b hack ệ ộ ị

- B ịcác chuyên gia cảnh báo v ề nguy cơ lỗ ổ h ng b o m t ả ậ

- R i ro v b o m t khi giao th c OAuth2 d a hoàn toàn vào Transport Layer ủ ề ả ậ ứ ựSecurity m b o t t c các d để đả ả ấ ả ữ liệu được truy n gi a các máy ch web và các ề ữ ủtrình duyệt được mang tính riêng tư, tách rời

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

3.1 Giớ i thi u mô hình ệ

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

3.1.1.1 Xây d ng Single sign-on v các nhà cung c p Provider ự ớ i ấ

Việc xây d ng h th ng Single sign-on s d ng OAuth2 v i gi i pháp l a ự ệ ố ử ụ ớ ả ựchọn các nhà cung c p OAuth2 ph bi n hi n nay là m t gi i pháp t t ấ ổ ế ệ ộ ả ố [11]: Google, Github, Gitlab, Facebook, Instagram, Okta, Paypal, Strava, Wordpress, Yahoo, Twitter, LinkedIn, Flickr, Bitbucket, AOL, Amazon…

Các nhà cung cấp Provider đều là nh ng nhà cung c p l n và thông d ng có ữ ấ ớ ụ

h ỗtrợ các thư viện, tài li u , gi i pháp tệ ả ốt… ới những ưu điểm: V

- L i ích c a vi c xây d ng h ợ ủ ệ ự ệthống SSO s d ng OAuth2 b ng các tích hử ụ ằ ợp

gi i pháp v i các nhà cung c p d ch v OAuth2 giúp ích cho doanh nghi p gi m bả ớ ấ ị ụ ệ ả ớt chi phí, th i gian, nhân l c xây d ng h ờ ự ự ệ thống SSO, vi c tích h p nhanh chóng và ệ ợkhá đơn giản

- Khả năng tích hợp h ệthống nhanh chóng, đơn giản

Các nhà cung c p OAuth2 ấ đều có lượng người dùng khá l n, khá ti n l i khi ớ ệ ợđược tích h p v i h th ng ợ ớ ệ ố Tuy nhiên nó cũng có mộ ố điểm chưa phù hợt s p v i ớ

nh ng h ữ ệ thống có m c tiêu xây d ng h ụ ự ệ thống Single sign-on c 2 phía Client và ảServer,

- Vi c tích h p v i các nhà cung c p OAuth2 khi n cho doanh nghi p hoàn ệ ợ ớ ấ ế ệtoàn ph thu c vào các Provider Các nghi p v xây d ng nghi p v xác thụ ộ ệ ụ ự ệ ụ ực được đóng kín, không thể can thi p ệ

- Vì một lí do nào đó, doanh nghiệp hoàn toàn có th b các nhà cung cể ị ấp Provider t ừchối, không còn h giao ỗtrợ thức… Điều này có th làm ể ảnh hướng đến nghi p v , h ệ ụ ệthống vốn đã ổn định và được xây d ng trên các nhà cung c p ự ấ

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

Việc xây d ng h th ng Single sign-on s d ng OAuth2 v i gi i pháp là m t ự ệ ố ử ụ ớ ả ộnhà cung c p Provider hiấ ện nay cũng được khá nhi u các ngôn ng , framework h ề ữ ỗtrợ: Java Spring Framework, PHP Laravel laravel-passport, Golang Ory Hydra …Các ngôn ngữ, framework đều là nh ng mã ngu n m (Open Source) có c ng ữ ồ ở ộđồng ngườ ử ụng đông đải s d o, cộng đồng người phát tri n r ng l n, d dàng ti p ể ộ ớ ễ ế

c n ngôn ng , framework Vi c xây d ng h ậ ữ ệ ự ệ thống v i gi i pháp trên là m t giớ ả ộ ải pháp t ốt

Giải pháp Java Spring Framework, Golang Ory Hydra là 2 Opensource có

cộng đồng s d ng l n, tin c y Vì v y c 2 giử ụ ớ ậ ậ ả ải pháp đều có những ưu điểm chung:

- L i ích c a vi c xây d ng h ợ ủ ệ ự ệ thống Single sign-on s dử ụng OAuth2 đóng vai trò là nhà cung c p Provider khi n cho doanh nghi p có th xây dấ ế ệ ể ựng được một

t p khách hàng cho riêng mình Gi i pháp cho phép doanh nghi p có th linh ho t, ậ ả ệ ể ạchủ độ ng trong vi c xây d ng các nghi p v Cho phép xây d ng module User v i ệ ự ệ ụ ự ớnhu c u riêng, cho phép xây d ng các Resource Server cầ ự ủa người dùng … là cơ sở

để xây d ng các nghi p v sau bán hàng, chiự ệ ụ ến lược, d ch v v i s h tr c a ị ụ ớ ự ỗ ợ ủArtifical Intelligence, Machine Learning …

- Giải pháp Golang Ory Hydra được vi t b i ngôn ng Golang có hiế ở ữ ệu năng vượt tr i Còn Java Spring Framework là giộ ải pháp được phát tri n b i ngôn ng ể ở ữJava đem lại m t h th ng ho t đ ng b n b , ộ ệ ố ạ ộ ề ỉ ổn định

C 2 giả ải pháp trên đều là m t trong nh ng l a ch n ộ ữ ự ọ hàng đầu v i nhớ ững điểm

mạnh riêng Tuy nhiên đều có m t s ộ ố nhược điểm l n có khi n cho nó không phớ ế ải

là m t 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 Client và Server ả

- Vi c xây d ng h ệ ự ệ thống g p khó nhiặ ều khó khăn về ặ m t tri n khai, chi phí, ểnhân sự… Nó chỉ phù h p v i doanh nghi p có m t h sinh thái l n, có t p khách ợ ớ ệ ộ ệ ớ ậhàng đủ ớn để l mu n xây d ng h th ng v i nhu c u phát tri n các nghi p v , d ch ố ự ệ ố ớ ầ ể ệ ụ ị

v , chiụ ến lược v i s h ớ ợ ỗ trợ ủa c Artifical Intelligence, Machine Learning … Điều này là điểm y u l n nh t c a h th ng Single sign-on ế ớ ấ ủ ệ ố

Trong s ố đó PHP Laravel, laravel -passport t ra phù h ỏ ợp hơn cả ở b i vi c có ệ

th ể xây d ng h ố ự ệ th ng nhanh chóng, nh g n, c ỏ ọ ộng đồng ngườ ử ụ i s d ng l n, s n ớ ự ổ

đị nh, d h c, d tri n khai, phù h p v i nh ng d ch v ễ ọ ễ ể ợ ớ ữ ị ụ thương mại điệ ử n t

3.1.3 Thự c tr ng và mô hình truy ạ ề n th ng ố

Hiệ ạn t i không có nhi u doanh nghiề ệp có đủ ềm năng, nhân lực để ti xây d ng ựđược 1 h sinh thái t t cho riêng mình Xây d ng 1 gi i pháp l n cho 1 bài toán nh ệ ố ự ả ớ ỏthường không ph i là cách các doanh nghi p tri n khai, hoả ệ ể ặc đặt m i quan tâm cho ố

những ngày đầu thành l p ậ

Do đó mỗ ịi d ch v thưụ ờng được xây d ng nghi p v t ự ệ ụ ừ đầu cho User, điều đó

l p l m i khi có m t dặ ại ỗ ộ ịch vụ ớ m i ra đời

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

Trước khi có đăng nhập m t lộ ần , người dùng phải đăng nhập các tài kho n, ả

mật khẩu cho t ng ng d ng m i khi h ừ ứ ụ ỗ ọ đăng nhập vào các ng d ng khác nhau ứ ụVới những doanh nghiệp đã xây dựng được hệ sinh thái cho riêng mình Điều này càng thể ệ hi n rõ việc tốn kém nhân lực, chi phí, thời gian các nghiệp vụ không thể tái sử dụng Với nghiệp vụ phân tích dữ u cliệ ủa mỗi người dùng để phụ ụ cho chiến lược c vkinh doanh, khó có th phân biể ệt được đâu là dữ liệu của người dùng trong 1 hệ sinh thái

Do đó nhu cầu xây d ng 1 h thự ệ ống đăng nhập m t lộ ần, là cơ sở để doanh nghi p có th ệ ểtriển khai các nghi p v c n thiệ ụ ầ ết cho chiến lược kinh doanh

Khi mà công ngh thông tin ngày càng phát tri n, d u th c s quan tr ng, ệ ể ữliệ ự ự ọthông tin cá nhân đặc biệt được quan tâm, cần được b o m t Thì gi i pháp xây ả ậ ả

d ng h ự ệ thống đăng nhập m t l n, s d ng OAuth2 th c s mang l i l i ích cho c ộ ầ ử ụ ự ự ạ ợ ảdoanh nghi p l n khách hàng ệ ẫ

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

Dựa trên nhược điểm c a vi c tri n khai h ủ ệ ể ệthống Single sign-on là t t kém v ố ề

m t nhân s , ngu n l c, thặ ự ồ ự ời gian và chi phí… Việc l a ch n gi i pháp PHP ự ọ ảLaravel Framework để xây d ng h th ng ph n nào h n ch ự ệ ố ầ ạ ế được nhược điểm mà

v n có kh ẫ ả năng đáp ứng nh ng yêu c u, tiêu chí cữ ầ ủa mộ ệ thốt h ng Single sign-on

Dựa trên nhu cầu mong mu n xây d ng 1 h ố ự ệthống Single sign-on:

- Là cơ sở để phát tri n các nghi p v Resource Server ể ệ ụ

- Khả năng tích hợp m t Application v i h thộ ớ ệ ống nhanh chóng, đơn ả gi n

- Khả năng mở ộ r ng khi nhu cầu tăng

- Khả năng xây dựng, phát tri n h th ng nhanh chóng ể ệ ố

- Opensource đượ ự ỗ ợc s h tr và phát tri n b i cể ở ộng đồng t t ố

V i nh ng lí do trên, m c tiêu khi xây d ng h ớ ữ ụ ự ệ thống tôi xin quyết định lựa chọn công ngh xây d ng giệ để ự ải pháp như sau:

✓ PHP 7.2 với FasstCGI Process Manager (php-fpm) cho nginx

✓ Session storage: Redis 5.0

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

3.1.6.1 Giớ i thi u về PHP ệ

PHP là vi t t t c a t ế ắ ủ ừ Hypertext Preprocessor , là một lo i ngôn ng l p trình ạ ữ ậ

k ch b n hay là m t lo i mã lị ả ộ ạ ệnh được dùng ch y u v i mủ ế ớ ục đích phát triển các

ứng d ng vi t cho máy ch , mã ngu n m PHP phù h p v i cho vi c xây d ng các ụ ế ủ ồ ở ợ ớ ệ ự

h ệthống website b i nó có tở ốc độ nhanh, nh gỏ ọn, cú pháp đơn giản

PHP là ngôn ng khá d hữ ễ ọc, đượ ử ục s d ng mi n phí, có th i gian xây d ng ễ ờ ự

s n ph m ng n Chính vì th PHP nhanh chóng tr thành ngôn ng l p trình web ả ẩ ắ ế ở ữ ậ

ph biổ ến và được ưa chuộng

Hình 11 : PHP được ưu chuộ ng làm n n t ề ảng chính để thiết kế web [9]

Một số lí do khiến PHP được ưu chuộng:

- Mã ngu n m : PHP là m t mã ngu n m ( Open Source) vì v y vi c tùy bi n ồ ở ộ ồ ở ậ ệ ếPHP là mi n phí và t do ễ ự PHP được h b i h u h t các WebServer thông d ng ỗtrợ ở ầ ế ụ

hiện nay như: Apache, ISS…

- Tính cộng đồng: Là m t trong nh ng ngôn ng ph biộ ữ ữ ổ ến, đượ ử ục s d ng r ng ộrãi, có cộng đồng người sử ụ d ng đông

Các b n c p nh t, vá l i liên tả ậ ậ ỗ ục được ậc p nh t khi n cho PHP ngày càng ậ ếhoàn thiện

Cộng đồng ngườ ử ụi s d ng l n, v i nhi u diớ ớ ề ễn đàn, blog v ềchủ đề PHP khiến cho quá trình tiế ập c n, tìm hiểu PHP được hưởng l i ợ

- Thư viện phong phú: Là m t ngôn ng mã ngu n mộ ữ ồ ở, PHP có được cho mình

1 cộng đồng phát tri n, h r t m nh m v ể ỗtrợ ấ ạ ẽ ề các thư viện JS, các framework l n ( ớLaravel, Yii2, Zend, CodeIgnier…), các hệ qu n tr (Joomla, Wordpress, ả ịDrupal…)…

- H ỗ trợ nhi u h ề ệ cơ sở ữ d u: Vi c h liệ ệ ỗ trợ nhiều cơ sở ữ d u: MySQl, liệMongoDB, Oracle, MS SQL… khiến cho vi c xây d ng ng d ng Web tr nên ti n ệ ự ứ ụ ở ệ

lợi và nhanh chóng

- Lập trình hướng đối tượng: V i vi c PHP h mô hình lớ ệ ỗ trợ ập trình hướng đối tượng (OOP) khi n cho l p trình viên d dàng ti p c n, phát tri n các ng d ng ế ậ ễ ế ậ ể ứ ụnhanh chóng và d dàng ễ

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]

- Tính b o m t: PHP là mã ngu n m , vả ậ ồ ở ới động đồng người dùng khá l n nên ớ

có thể nói PHP khá an toàn v b o m t và sự ổn địề ả ậ nh

- Khả năng mở ộ r ng: Xây d ng trên n n ngôn ng C và là mã ngu n m nên ự ề ữ ồ ở

kh ả năng mở ộ r ng c a PHP là không giủ ới hạn

3.1.6.2 Giớ i thi u về framework Laravel ệ

Laravel là một PHP Framework mã ngu n m , mi n phíồ ở ễ , được xây d ng và ựphát tri n b i Taylor Otwell Laravel h ể ở ỗ trợ phát tri n các ng d ng web theo c u ể ứ ụ ấtrúc Model-View-Controller ( mô hình MVC)

Điểm m nh c a Laravel là cú ạ ủ pháp đơn giản, rõ ràng, có h thệ ống đóng gói Modular và qu n lí gói ph thu c, nhiả ụ ộ ều cách khác nhau để truy cập cơ sở ữ d liệu quan h , không quan h Phát tri n nhi u ệ ệ ể ề thư viện h cho vi c xây d ng và b o ỗtrợ ệ ự ảtrì ứng d ng ụ

Laravel ra đời vào tháng 06/2011, tuy v y vậ ới các điểm m nh cạ ủa mình đã khi n Laravel hi n gi là frameworế ệ ờ k được ưa chuộng, và có được m t cộ ộng đồng đông nhất

Hình 13 : Sự tăng tưở ng c a Laravel trên Github ủ [11]

- D dàng s d ng: Laravel r t d ễ ử ụ ấ ễ dàng để ử ụng, do đó nó đượ s d c cộng đồng đón nhận và s d ng nhi u ử ụ ề