Authentication and Authorization

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