authentication and authorization
TRANSCRIPT
PHAN ĐỨC VIỆT
ROLE - PERMISSIONSJWT - SESSION/COOKIE - BASIC AUTHOAUTH 2
PHÂN QUYỀN - XÁC THỰC
XÁC THỰC
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
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.
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:
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.
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.
REFRACTOR
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
HTTPS://GITHUB.COM/PADUVI/USER-SERVICE-BACKEND-DEMO
THAM KHẢO:
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ĩ…
BASIC AUTH
JWT (JSON WEB TOKEN)
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
GỒM 3 PHẦN
HEADER
Mã hóa Base64URL
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
PAYLOADPUBLIC
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
PAYLOAD
Mã hóa Base64URL
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:
KHI NÀO DÙNG JWT
COOKIE VS JWT
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.
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
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
OAUTH 2
Ứ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
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’
DONEC QUIS NUNC
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 đó
ĐƯỜ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=banAnhViet&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.
SỬ DỤNG ACCESS TOKEN
BƯỚC 4
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
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