Tài liệu trình bày các khái niệm về phân quyền và xác thực trong ứng dụng, bao gồm việc sử dụng JWT, session/cookie, và OAuth 2. Nó cũng đề xuất các cách quản lý quyền truy cập người dùng thông qua enum và cơ sở dữ liệu, đồng thời đưa ra so sánh giữa JWT và các phương thức xác thực khác. Cuối cùng, tài liệu hướng dẫn quy trình xác thực và cấp token cho người dùng trong ứng dụng.

1. PHAN ĐỨC VIỆT
ROLE - PERMISSIONS
JWT - SESSION/COOKIE - BASIC AUTH
OAUTH 2
PHÂN QUYỀN - XÁC THỰC

2. XÁC THỰC

3. PHÂN QUYỀN
• Giới hạn quyền truy cập người dùng:
• Client/Member (Trang Frontend)
• Admin (Trang Backend)
• Ý tưởng giải quyết cơ bản: sử dụng Enum để phân biệt Role của người dùng. Ví dụ:
• [0]: Admin, [1]: Member
• True: Admin, False: Member

4. NẾU CÓ NHIỀU HƠN 2 ROLE
VẤN ĐỀ
• if (role == 3)?
• if (role == 10)?
• if (role == 30)?
• Làm sao để nhớ hết được Enum nào ứng với Role nào?
• Dependency Injection: lưu vào trong 1 file config.xml hay config.json,…
• Sử dụng Database: Sử dụng 1 bảng riêng để lưu trữ danh sách các Role. ID của
Role sẽ chính là Enum.

7. PHÂN QUYỀN
• 1 User có thể có nhiều Role?
• 1 tác vụ chỉ cho phép vài Role nhất định được phép thực thi:

8. CHIA NHỎ THÀNH CÁC AGGREGATE
HÃY CHIA NHỎ HỆ THỐNG!!!
• Thế nào là Aggregate:
• Post - Comment - Like: Post là một Entity còn các Like và Comment là những
Entity khác hoặc cũng có thể là Value Object , chúng nằm trong một mối quan hệ
kết tập gọi là Aggregate.
• Order - OrderItem
• Aggregate Root: là Post, Order, còn các object khác như Like hay Comment sẽ được
xác định theo Aggregate và mỗi object sẽ có một local ID.

9. XÁC ĐỊNH AGGREGATE ĐỂ LÀM GÌ?
• Aggregate được xác định dựa trên logic nghiệp vụ -
> use case.
• Bên trong Aggregate chia thành các Permission:
VD: ‘manage_all_order’, ‘manage_own_order’
• Lưu trong config hoặc DB đều được.

10. REFRACTOR

11. LƯU TRỮ PERMISSION ĐI KÈM VỚI ROLE
• SQL:
• Sử dụng 1 Bảng RolePermission để lưu các Permission đi kèm với Role
• Mã hóa lại dưới dạng JSON Text rồi lưu vào trong trường permissions của bảng
Role
• Đối với Postgresql: lưu trường permissions dưới dạng JSON/JSONB
• NoSQL:
• Lưu danh sách permissions trực tiếp vào trong bản ghi Role

12. HTTPS://GITHUB.COM/PADUVI/USER-SERVICE-BACKEND-DEMO
THAM KHẢO:

13. SESSION - COOKIE
Server
- Session: Cache, Database,… gọi
chung là Session Store
Client
- Cookie: trình duyệt quản lý, không
tới lượt mình lo nghĩ…

14. BASIC AUTH

15. JWT (JSON WEB TOKEN)

16. NÓ LÀ 1 CÔNG CỤ ĐỂ TRUYỀN TIN RẤT HỮU HIỆU
JWT KHÔNG ĐƠN THUẦN CHỈ ĐỂ XÁC THỰC

17. GỒM 3 PHẦN

18. HEADER
Mã hóa Base64URL

19. PAYLOAD
• iss (issuer): tổ chức phát hành token
• sub (subject): chủ đề của token
• aud (audience): đối tượng sử dụng token
• exp (expired time): thời điểm token sẽ hết hạn
• nbf (not before time): token sẽ chưa hợp lệ trước thời điểm này
• iat (issued at): thời điểm token được phát hành, tính theo UNIX time
• jti: JWT ID
RESERVED

20. PAYLOAD
PUBLIC

21. PAYLOAD
• Phần thông tin thêm dùng để truyền qua giữa các máy thành viên.
• Không được đặt khóa trùng với Reserved Key
PRIVATE

22. PAYLOAD
Mã hóa Base64URL

23. DÙNG ĐỂ XÁC THỰC
SIGNATURE
Phần chữ ký được tạo bằng cách kết hợp 2 phần Header + Payload, rồi mã
hóa nó lại bằng giải thuật encode mà ta đã khai báo ở phần Header, càng
phức tạp thì càng tốt, ví dụ như HMAC SHA-256:

24. KHI NÀO DÙNG JWT

25. COOKIE VS JWT

26. JWT VS COOKIE
JWT
• Không bị ảnh hưởng bởi CORS
• Phải config request
• Không cần sử dụng Session Store, bản thân
Token cũng có thể chứa được data
• Có thể sử dụng HTML5 Local Storage để lưu
trữ Token ở Browser -> tránh được tấn công
CSRF
• Thích hợp với mô hình Stateless, hoặc mở
API cho ứng dụng từ phía ngoài (Cross
Domain Ajax, Mobile App) -> gần như nếu
muốn triển khai MicroService thì bắt buộc phải
dùng JWT
Cookie
• Bị ảnh hưởng bởi CORS
• Không cần phải config request
• Phải dùng Session Store
• Nhược điểm lớn nhất: dễ bị lợi dụng để tấn
công CSRF -> người lập trình Backend sẽ rất
mệt mỏi khi xử lý dữ liệu do hacker nhúng vào
• Thích hợp trong mô hình Stateful và kiến trúc
Monolitic truyền thống.

27. JWT VS BASIC AUTHENTICATE
JWT
• Không giải mã được Token
• Có thể dùng trong truyền tin
Basic Authenticate
• Có thể dùng trong truyền tin
• Chỉ dùng được trong Authentication

28. JWT VS OAUTH 2
• Chú ý:
• JWT là chuẩn giao thức Authenticate
• OAuth2 là mô hình Authenticate
• Bên trong OAuth2 cũng có thể sử dụng JWT để làm Token:
https://help.salesforce.com/HTViewHelpDoc?id=remoteaccess_oauth_jwt_flow.htm
• Tham khảo thêm về JWT:
https://techmaster.vn/posts/33959/khai-niem-ve-json-web-token
• Sử dụng Local Storage:
http://www.w3schools.com/html/html5_webstorage.asp

29. OAUTH 2

30. ỨNG DỤNG CẦN PHẢI XIN PHÉP MÁY CHỦ LƯU TRỮ THÔNG TIN USER
BƯỚC 1
• Ứng dụng sẽ gửi lên cho máy chủ User Service các thông tin:
• App ID
• App Secret Key
• Scope (Domain muốn truy cập)
• Phía ngược lại, khi nhận được request của ứng dụng, User Service sẽ kiểm tra xác thực thông tin
ứng dụng và check các domain ứng dụng yêu cầu. Nếu ok thì sinh ra 1 đoạn mã Token
(AuthCode):
• Ta có thể sử dụng JWT ở bước này
• Sinh code random rồi lưu trong database

31. BƯỚC 2
• Sau khi sinh ra AuthCode, User Service sẽ chuyển hướng sang trang giao diện Đăng
nhập của chính nó:
http://localhost:411/login?authCode=abcxyz.mnb.opq&scope=user,course
• Thông thường hệ thống nhỏ thì có thể chưa cần tới khái niệm scope, tuy nhiên nếu
hệ thống lớn sẽ cần tới Scope. VD như Facebook: ‘timeline’, ‘page’, ‘group’

32. DONEC QUIS NUNC

33. XỬ LÝ THÔNG TIN ĐĂNG NHẬP NGƯỜI DÙNG
BƯỚC 3
• Kiểm tra:
• Scope mà ứng dụng gửi lên có hợp lệ hay không?
• User có đăng nhập đúng username, password không?
• Kết quả:
• Thành công: chuyển hướng về trang Success Callback mà ứng dụng đã khai báo
trước đó
• Thất bại: chuyển hướng về trang Fail Callback mà ứng dụng đã khai báo trước đó

34. ĐƯỜNG DẪN SUCCESS THƯỜNG CÓ DẠNG NHƯ SAU:
BƯỚC 3
• ${success_callback_uri}?accessToken=accessToken&refreshToken=refreshToken&…
• Ví dụ:
http://localhost:8080/auth/success?accessToken=abc.xyz.lmn&refreshToken=banAn
hViet&authScheme=Bearer
• Ta có thể hiểu việc chuyển hướng trang web nó giống như là đang truy cập tới 1
Route với phương thức GET. Như vậy: Ứng dụng sẽ bóc tách các Param URL rồi lưu
lại vào trong Html5 Local Storage.

35. SỬ DỤNG ACCESS TOKEN
BƯỚC 4

36. SỬ DỤNG REFRESH TOKEN
• Khi người dùng đăng nhập, tạo 1 bản ghi trong DB lưu lại
- user_id
- refresh_token
- expired_time
• Lấy ID của bản ghi vừa tạo, nhét vào trường jti (jwtID) của payload accessToken.
• Khi AccessToken hết hạn, gửi AccessToken và RefreshToken lên User Service, trên
đó check:
• jti và refresh_token khớp nhau không?
• nếu có thì generate ra accessToken, refreshToken mới

37. LINK DEMO:
• Backend (User Service): Sử dụng ActionHero, Sequelize:
https://github.com/paduvi/user-service-backend-demo
• Frontend (Application): Sử dụng ReactJS:
https://github.com/paduvi/user-service-frontend-demo