1. Đặt vấn đề. ............................................................................................................................. 3 2. Lý thuyết triển khai. ............................................................................................................. 3 2.1. Các vai trò (roles) trong giao thức .................................................................................. 3 2.1.1. Client ......................................................................................................................... 3 2.1.2. Resource server ......................................................................................................... 4 2.1.3. Resource owner ......................................................................................................... 4 2.1.4. Authorization server.................................................................................................. 4 2.2. Protocol Flow .................................................................................................................. 5 2.3. Protocol endpoint ............................................................................................................ 7 2.3.1. Authorization endpoint.............................................................................................. 7 2.3.2. Token endpoint .......................................................................................................... 7 2.4. Refresh token ................................................................................................................... 7 2.5. Authorization Grant ........................................................................................................ 8 2.5.1. Authorization code .................................................................................................... 9 2.5.2. Implicit .................................................................................................................... 10 2.5.3. Client credentials .................................................................................................... 12 2.5.4. Resource owner password credentials (ROPC) ..................................................... 13 3. Kết luận ................................................................................................................................ 13 4. Tài liệu tham khảo .............................................................................................................. 14
ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ XÁC THỰC VÀ PHÂN QUYỀN TRÊN CÁC HỆ THỐNG PHÂN TÁN VỚI OAUTH2 Môn học: Các vấn đề đại ngành kỹ thuật máy tính Sinh viên : Bùi Huy Đông Mã sinh viên : 20020647 Hà Nội, 03/12/2023 MỤC LỤC Đặt vấn đề Lý thuyết triển khai 2.1 Các vai trò (roles) giao thức 2.1.1 Client 2.1.2 Resource server 2.1.3 Resource owner 2.1.4 Authorization server 2.2 Protocol Flow 2.3 Protocol endpoint 2.3.1 Authorization endpoint 2.3.2 Token endpoint 2.4 Refresh token 2.5 Authorization Grant 2.5.1 Authorization code 2.5.2 Implicit 10 2.5.3 Client credentials 12 2.5.4 Resource owner password credentials (ROPC) 13 Kết luận 13 Tài liệu tham khảo 14 Đặt vấn đề - Trong thời đại công nghệ nay, việc liên kết tương tác ứng dụng phân tán tốn khơng gặp Tuy nhiên để đảm bảo an tồn, bảo mật có tính cá nhân hố cho trường hợp lại tốn lớn - Để giải toán triển, Oauth2 giải pháp tối ưu sử dụng rộng rãi OAuth 2.0 (Open Authorization 2.0) giao thức ủy quyền phổ biến sử dụng để quản lý quyền truy cập vào tài nguyên ứng dụng khác Đây phương tiện quan trọng để giải nhiều vấn đề liên quan đến việc quản lý ủy quyền truy cập bảo mật hệ thống phân tán Bài tiểu luận tập trung vào lý thuyết triển khai, Oauth2 Lý thuyết triển khai 2.1 Các vai trò (roles) giao thức 2.1.1 Client - Là ứng dụng sau: + WebApp + NativeApp: Desktop App, Postman + SinglePageApp: Angular, Vue - Là ứng dụng đại diện cho người dùng, thực yêu cầu lấy tài nguyên tương ứng người dùng 2.1.2 Resource server - Là Web API - Quản lý tài nguyên người dùng 2.1.3 Resource owner - Là người dùng cuối (end-user) - Người dùng cuối thành phần phân quyền truy cập đến tài nguyên tương ứng, cách xác thực hay nhấn Allow/Deny chẳng hạn - Khi Client WebApp, Resource_Owner tương tác với Client thơng qua User_Agent, trình duyệt web 2.1.4 Authorization server - Ví dụ ứng dụng sau: + KeyCloak + Microsoft Entity Platform + Google OAuth2 Service - Là máy chủ cung cấp giao diện cho phép người dùng cuối Allow/Deny yêu cầu truy nhập tài nguyên - Trong ứng dụng thơng thường, Authorization_Server Web_API (Resource_Server) - Trong ngữ cảnh rộng hơn, Authorization_server thành phần, máy chủ tách biệt so với Web_API 2.2 Protocol Flow Client mong muốn truy cập đến tài nguyên, Client request đến Resource_Owner (EndUser) để xin quyền truy cập Request gửi đến user cách: (A) - Trực tiếp: Ví dụ client hiển thị ln cho user Allow/Deny, Client hiển thị form đăng nhập - Gián tiếp: Thông qua giao diện Authorization_Server Tức dùng form đăng nhập hay phương thức xác thực khác Authorization_Server User nhận thông báo yêu cầu truy cập tài nguyên từ Client (B) - Ví dụ Google hiển thị trình duyệt “Cho phép medium.com sử dụng thông tin sau…” hay cách iphone hiển thị message “Cho phép AppleID đăng nhập từ thiết bị/trình duyệt…” - Tùy theo type request bước (A), thông báo, thông tin User cần cung cấp khác nhau: ví dụ nhập username/password, nhập Code, Allow/Deny,… - Sau User (resource_owner) cho phép (grant), Client nhận Authorization_Grant khác tùy vào type bước (A) + Raw username/password user; + Code đại diện cho username/password xác thực user; + … Client cầm Authorization_Grant có từ bước (B), gửi đến Authorization_Server để xin Access_Token (tiêu biểu Bearer Token – jwt) (C) Ở ta thấy rõ, Access_Token Authorization_Server cấp Web_API cấp Thông thường ngữ cảnh hẹp, thành phần nên ta khó phân biệt Authorization_Server xác thực (authenticate) Client, xác nhận (validate) lại (D) Author_Grant có hợp lệ khơng; Nếu yếu tố hợp lệ, cấp Access_Token cho Client (E) Client sử dụng Access_Token để request đến tài nguyên cần truy cập Resource_Server (Web_API) – Dùng RestAPI với header Authorization chẳng hạn Resource_Server xác nhận (validate) Access_Token, trả tài nguyên cần truy xuất hợp lệ (đúng user, role chẳng hạn) (F) OAuth2 không quy định Access_Token, việc Resource_Server Authorization_Server, JWT cách thường dùng → Giả sử Access_Token JWT, làm để WebAPI (Resource Server) xác nhận JWT Authorization Server cấp phát hợp lệ? - Lâu dùng Spring chẳng hạn, JWT tạo xác thực Spring Security, với key mã hóa cấu hình từ trước Vì vấn đề dễ xử lý giải mã được, Spring Security (Authorization_Component) WebAPI (Resource_Component) ứng dụng 2.3 Protocol endpoint - OAuth2 yêu cầu Author_Server phải cung cấp endpoint, hiểu API: Authorization endpoint Token endpoint - OAuth2 quy định Client phải cung cấp Redirection endpoint, Author_Server phản hồi kết cho Client, thông qua User_Agent người dùng 2.3.1 Authorization endpoint - Là form xác thực Author_Server dành cho User (resource_owner), Client redirect đến thơng qua user_agent, POST liệu đến Author_Server - Thơng thường action: /authorize /auth 2.3.2 Token endpoint - Dành cho Client gửi lên authorization_grant để lấy Access_Token từ Author_Server; - Thông thường action: /token 2.4 Refresh token - Là loại token Authorization_Server cấp cho Client - Refresh_token Client dùng để thay cho user_credentails access_token hết hạn sử dụng + Điều có nghĩa user khơng cần đăng nhập lại access_token hết hạn - Khi access_token hết hạn, Author_Server trả lỗi invalid_token_error - Client gửi refresh_token cấp trước đến Auth_server, refresh_token hợp lệ, Author_server trả access_token refresh_token 2.5 Authorization Grant - Flow OAuth2 cho thấy, Client muốn truy cập đến Resource, cần User tương ứng cấp quyền truy cập Và thông thường hành động thông qua giao diện xác thực, xác nhận: - Ví dụ trên, ta thấy: + Client = MyLoginApp (ExampleApp) + Authorization_Server = Google OAuth + User xác nhận cách đăng nhập email/password với Form đăng nhập từ Authorization_Server → authorization request gửi đến user cách gián tiếp thơng qua giao diện AuthorServer → Trực tiếp MyLoginApp (Client) tự hiển thị giao diện đăng nhập - OAuth2 định nghĩa cách cho Authorization_Grant 2.5.1 Authorization code - Client yêu cầu User đăng nhập username/password giao diện Authorization_Server, tức theo cách gián tiếp + Client biết tài khoản User: user_credentials - Đăng nhập thành công, Author_Server thực hiện: + Redirect trang Callback Client (redirectionEndpoint đăng ký với AuthorServer từ trước) + Gửi trang Callback đoạn mã gọi authorization_code kèm theo redirect - Client sử dụng Authorization_Code + client_credentials gửi đến Author_Server để lấy Access_Token + client_credentials khác với user_credentials 2.5.2 Implicit - Với type=Implicit, Author_Server trả access_token từ /auth endpoint thay /token endpoint - User xác thực username/password giao diện Author_Server, xác thực thành công Author_Server redirect trang callback Client, kèm theo access_token query, ví dụ id_token=eyJ đây: GET https://localhost/myapp/# code=0.AgAAktYV-sfpYESnQynylW_UKZmH-C9y_G1A &id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q - Implicit type thiết kế dành cho Client SPA – single page app – mà toàn source Client JS host trình duyệt + Khi đó, source code available cho user, nên maintain client_credentials cách bảo mật so với trường hợp type=authorization code + Mà khơng cần maintain client_credentials, thay trả author_code, author_server trả ln access_token 2.5.2.1 - Hạn chế thiếu bảo mật access_token Implicit Implicit không khuyến nghị sử dụng nữa, thay vào sử dụng authorization_code - Bởi access_token redirect trực tiếp Client thông qua callback_url https://piedpiper.com/#token-goes-here + đó, tất script code trình duyệt web user lấy access_token (như từ thư viện JS) - Ví dụ source code SPA: - Và JS code thư viện “a-library-found-online…” lấy access_token: 2.5.2.2 - Hạn chế long-live SSO Thông thường Client mong muốn hỗ trợ long-live SSO, với trường hợp refresh_token sử dụng để tránh user phải đăng nhập lại nhiều lần - Implicit khơng hỗ trợ refresh_token, thực tế, OpenId Connect protocol dựa OAuth2, quy định phương thức gọi silent_redirect: + Cứ khoảng time, client sử dụng hidden iframe cho url: http://author_server.com/oauth/auth?prompt=none nhận access_token từ callback - Nguyên tắc hoạt động silent_redirect dựa hidden_iframe, sử dụng cookie (sessionID) url đích, cookie domain author_server - Kể từ 03/2020, Apple chặn tính cho phép truy cập vào cookie domain khác Safari (block third-party cookie) – chống tracking người dùng; sau Firefox triển khai tính này; Chrome có kế hoạch vào 2023 + Do long-live SSO với Implicit khơng khả thi 2.5.3 Client credentials - Đây kiểu Authorization Grant dùng trường hợp tương tác server-to-server, hay service account: + Tức q trình authorization khơng có tham gia Resource_Owner (User) + Hoàn toàn giữa: Client-AuthorServer - Do đó, với type này, Client truy cập đến resource mà phạm vi truy cập Client, resource User + Hiểu nôm na đây, với ngữ cảnh cần phân biệt User1 User2 để hiển thị chức với type không khả thi - Client gửi client_credentials gồm: client_id + client_secret (đã AuthorServer) cấp phát từ trước + Author_Server xác thực client_credentials valid, trả access_token 2.5.4 Resource owner password credentials (ROPC) - user_credentials (username + password) Client sử dụng, kết hợp với client_credentials (client_id + client_secret) gửi đến /token endpoint: + Author_Server xác thực user_credentials + client_credentials, valid trả access_token - Với type=ROPC, Client biết được, quản lý user_credentails, khơng thể có tính bảo mật cao type=Authorization Code - Và hạn chế long-live SSO nhược điểm type Kết luận - Oauth giúp ta giải nhiều vấn đề liên kết hệ thống phân tán: + Ủy quyền: OAuth 2.0 cho phép người dùng cấp quyền truy cập vào tài nguyên mà họ sở hữu mà khơng cần chia sẻ mật Điều giúp bảo vệ mật người dùng tăng cường bảo mật + Quản lý quyền truy cập: OAuth 2.0 cung cấp cách linh hoạt để quản lý quyền truy cập tài nguyên Người dùng chọn cấp quyền truy cập đọc, ghi, hai cho ứng dụng bên thứ ba mà không cần chia sẻ mật + Chia sẻ Tài nguyên An toàn: OAuth 2.0 giúp đảm bảo quyền truy cập vào tài nguyên thực người ủy quyền, thông qua cách thức an tồn + Tích hợp dễ dàng: OAuth 2.0 cung cấp giao thức chuẩn hóa, giúp việc tích hợp ứng dụng dịch vụ trở nên dễ dàng Các nhà phát triển sử dụng thư viện khung làm việc hỗ trợ OAuth 2.0 để triển khai việc ủy quyền cách hiệu + Phân tán Tương tác Giữa Ứng dụng: OAuth 2.0 cho phép ủy quyền ứng dụng không cần tương tác trực tiếp với người dùng Điều hữu ích kịch nơi ứng dụng cần truy cập tài nguyên mà không cần liên quan trực tiếp đến người dùng Tài liệu tham khảo https://oauth.net/2/ https://datatracker.ietf.org/doc/html/rfc6749