Tìm hiểu giao thức Oauth và xây dựng ứng dụng thử nghiệm

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG BÁO CÁO BÀI TẬP LỚN AN NINH MẠNG Đề tài Tìm hiểu giao thức Oauth và xây dựng ứng dụng thử nghiệm Lớp LTU15 Nhóm 4 1 Phạm Thị Qu.

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG BÁO CÁO BÀI TẬP LỚN AN NINH MẠNG Đề tài: Tìm hiểu giao thức Oauth xây dựng ứng dụng thử nghiệm Lớp : LTU15 Nhóm Phạm Thị Quỳnh - 20168447 Nguyễn Thị Thu Trang - 20168823 Trần Văn Lượng - 20168326 Giảng viên: ThS Bùi Trọng Tùng Lời nói đầu Hiện số lượng ứng dụng phát triển cách chóng mặt, bao gồm ứng dụng giải trí (nghe nhạc, xem phim, game … ) , ứng dụng đọc tin tức (báo điện tử, blog, …) nhiều loại ứng dụng khác Vấn đề đặt ứng dụng có chế quản lý người dùng riêng, thử tưởng tượng bạn phải đăng ký khoảng 10-20 ứng dụng với username password khác nhau, lại xác nhận qua email thật thảm họa Và chuẩn đời , có tên Open Authentication Open Authorization Trong báo cáo này, nhóm em xin trình bày vấn đề lịch sử, khái niệm Oauth, Cách thức hoạt động Oauth, so sánh Oauth với tảng khác sử dụng OpenID, … Xây dựng ứng dụng thử nghiệm có ứng dụng Oauth Mục lục Lời nói đầu I.Khái niệm Oauth II.Lịch sử Oauth III Thành phần mơ hình Oauth IV: Mơ hình hoạt động Oauth 1.Mơ hình chung 2.Các dạng cấp ủy quyền 2.1 Dạng cấp ủy quyền sử dụng mã ủy quyền 2.2 Cấp ủy quyền ngầm định 11 2.3 Cấp ủy quyền thông tin người dùng 13 2.4 Cấp ủy quyền thông tin ứng dụng 15 V.Vấn đề bảo Oauth 16 Oauth1 16 Oauth2 19 VI.So sánh Oauth chuẩn khác 1.Oauth SSO 20 Oauth OpenID 21 Oauth1.0 Oauth2.0 22 VII.Xây dựng ứng dụng demo 23 Phân Công Công Việc Nguyễn Thị Thu Trang Tìm hiểu khái niệm, lịch sử phát triển Oauth Vấn đề bảo mật Oauth Trần Văn Lượng Các khái niệm dùng Oauth Phạm Thị Quỳnh Cách thức hoạt động Oauth I Khái niệm OAuth ·         OAuth phương thức chứng thực giúp ứng dụng chia sẻ tài nguyên với mà không cần chia sẻ thông tin username password Từ O – Open Auth mang nghĩa :  Authentication: xác thực người dùng thông qua việc đăng nhập Authentication factor:xác định yếu tố khác để hệ thống xác thực người dùng, có cách: o Single-Factor Authentication:   là phương thức đơn giản , thường dựa vào mật đơn giản để cấp cho người dùng quyền sử dụng hệ thống(website).Người dùng cần nhập email/user + password xác minh danh tính o Two-Factor Authentication : phương thức xác thực bước Không nhập mật username/email mà thứ mà người dùng biết để đảm bảo mức độ bảo mật bổ sung o Multiple-Factor Authentication: phương thức  xác thực tiên tiến nhất, sử dụng hai nhiều mức bảo mật từ loại xác thực độp lập để cấp quyền cho người dùng truy cập hệ thống ( Các tổ chức tài ,ngân hàng, cơ  quan pháp luật sử dụng xác thực nhiều yếu tố để bảo vệ liệu ứng dụng họ khỏi mối đe dọa tiềm ẩn  Authorization : cấp quyền truy cập tài nguyên o Xảy sau hệ thống xác thực người dùng thành công o Authorization xác định khả truy cập hệ thống bạn mức II. Lịch sử  OAuth: - - Năm 2006, Twitter phát triển hệ thống OpenID phục vụ cho đăng nhập ứng dụng hệ thống Twitter-được coi chuẩn OAuth OpenID tiêu chuẩn mở (open standard) dùng cho việc xác thực người dùng thông qua nhà cung cấp dịch vụ OpenID gọi OpenID provider (như Google, Facebook, Twitter ) sử dụng việc xác thực OpenID hỗ trợ phát triển tổ chức phi lợi nhuận OpenID Foundation Năm 2010, IEFT – Tổ chức quản lý tiêu chuẩn mạng Internet – phát hành phiên thức OAuth 1.0.  Năm 2012,  OAuth2 đời, lỗi bảo mật sử dụng rộng rãi Oauth2 không đon giao thức kết nối, “Framework” – tảng mà triển khai bên : client Server III.Thành phần mơ hình Oauth Có thành phần Resource Owner, Resource Server, Client, Authorization Server  Resource Server : Là máy chủ cung cấp API , nơi mà người dùng tạo, sửa đổi xóa ghi , tài liệu tệp  Client: Ứng dụng bên thứ muốn truy cập vào tài khoản người dùng.  Có thể ứng dụng website  Resource Owner: Duy trì quyền sở hữu tài nguyên tạo sửa máy chủ người ủy quyền cho ứng dụng bên thứ truy cập tài khoản họ ( Người dùng )  Authorization Server: Khi bạn muốn rút khỏi máy chủ authorization từ máy chủ resource IV Mô Hình hoạt động Oauth Mơ hình chung Mơ hình thực bao gồm bước sau Ứng dụng yêu cầu ủy quyền từ service tới người dùng để truy cập tài nguyên nguwofi dùng sở hữu có khả truy cập Giả sử người dùng cho phép, cấp cho ứng dụng chứng nhận ủy quyền( Authorization Grant) Sau nhận chứng nhận ủy quyền, ứng dụng gửi chứng nhận tới máy chủ Authorization yêu cầu truy cập tài nguyên Khi xác định chứng nhận ủy quyền đúng, máy chủ Authorization cấp lại cho ứng dụng access Token nhất, cấp quyền cho ứng dụng truy cập phép sử dụng taì nguyên Ứng dụng gửi access Token đến máy chủ tài nguyên yêu cầu tài nguyên Nếu acess Token hợp lệ, máy chủ tài nguyên cung cấp tài nguyên người dùng cho ứng dụng truy cập Cấp ủy quyền Trong mơ hình trên, bước đầu để lấy mã ủy quyền (Authorization code) thẻ truy cập (Access Token) Sau ứng dụng lấy thơng tin người dùng OAuth có dạng ủy quyền 2.1 Dạng cấp quyền sử dụng mã ủy quyền Đây loại ứng dụng phổ biến viif tối ưu hóa cho ứng dụng phía máy chủ, nơi mã nguồn khơng cơng khai Để sử dụng cách thức ủy quyền này, ứng dụng phải có khả tương tác với người dùng (Ví dụ ứng dụng thiết lập giao diện đăng nhập facebook) nhận mã ủy quyền từ nguwofi dùng thông qua giao diện nhận mã ủy quyền từ người dùng thông qua giao diện Các bước cấp ủy quyền sử dụng mã ủy quyền : Người dùng truy cập ứng dụng Ứng dụng đưa hình đăng nhập có lựa chọn sử dụng ứng dụng Oauth(facebook, google, twitter,…) Người dùng chọn đăng nhâp máy chủ ủy quyền Bản chất người dùng gửi request sau: https://www.facebook.com/v3.0/dialog/oauth? client_id=441817523214128&redirect_uri=http%3A%2F%2Flocalhost %2FprojectAbc%2Fpublic%2Fauth%2Ffacebook%2Fcallback %2F&scope=email&response_type=code&state=qfRzuX9WR9HQqhOMscfzp fhVXPJU5KQOYqE4zFOt Request gửi có dạng https://www.facebook.com/v3.0/dialog/oauth: Máy chủ ủy quyền client_id: client ID ứng dụng, giúp máy chủ ủy quyền nhận dạng ứng dụng redirect_uri: CALLBACK_URL: đường dẫn trả chuyển hướng nguời dùng sau kiểm tra response_type=code: xác định kiểu trả mã ủy quyền scope=email: mức độ truy cập vào tài nguyên Máy chủ ủy quyền kiểm tra thông tin cảnh báo quyền hạn ứng dụng Gửi lại cho ứng dụng khách mã ủy quyền  Mã ủy quyền gửi qua redirect URL với tham số : + code: sinh máy chủ ủy quyền Thường hết hạn thời gian ngắn Máy khách sử dụng mã ủy quyền lần Những lần truy cập sau máy chủ ủy quyền có quyền từ chối truy cập + state: tham số gửi trình truyền authorization request gửi lại máy khách  Mã ủy quyền sinh từ thư viện JWT gồm phần : header, payload signature ngăn cách dấu chấm (.) Ví dụ mã ủy quyền eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjEzODY4OTkxM zEsImlzcyI6ImppcmE6MTU0ODk1OTUiLCJxc2giOiI4MDYzZmY0Y2ExZTQ xZGY3YmM5MGM4YWI2ZDBmNjIwN2Q0OTFjZjZkYWQ3YzY2ZWE3OTdiNDYxN GI3MTkyMmU5IiwiaWF0IjoxMzg2ODk4OTUxfQ.uKqU9dTB6gKwG6jQCuXY AiMNdfNRw98Hw_IWuA5MaMo + phần header: loại token (mặc định JWT- cho biết loaiij token JWT) thuật tốn dùng để mã hóa HMAC SHA256- HS256 RSA + payload: chứa claims Claims biểu thức thực thể( chẳng hạn user) số metadata phụ trợ Đây số metadata định nghĩa trước, số metadata bắt buộc, số lại nên tuân theo để JWT hợp lệ đầy đủ thông tin: iss (issuer), iat (issued-at time) exp (expiration time), sub (subject), aud (audience), jti (Unique Identifier cho JWT, +Signature: Chữ ký Signature JWT chuỗi mã hóa header, payload với chuỗi bí mật theo nguyên tắc sau: HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret) Người dùng xác nhận cấp quyền cho ứng dụng Ứng dụng có mã ủy quyền thực yêu cầu máy chủ ủy quyền 10 cung cấp access token cách gửi client id, client secret mã ủy quyền dạng POST  Máy chủ ủy quyền kiểm tra client id, client secret, mã ủy quyền (authorization code) không thấy bất thường gửi trả lại ứng dụng access token + Mã ủy quyền thường hết hạn thời gian ngắn, sinh từ thông tin người dùng nên đảm bảo tính bí mật + access token sinh cách dùng thư viện JWT máy chủ ủy quyền +access Token có thời gian sống trả access Token Người dùng đăng nhập thành công Người dùng truy cập vào hệ thống 10 Hệ thống gửi access Token đến máy chut ài nguyên yêu cầu tài nguyên 11 Máy chủ tài nguyên kiểm tra access token với máy chủ ủy quyền Nếu access Token trả liệu cho máy khách 12 Máy khách nhận liêu từ máy chủ tài nguyên 13 Hiển thị liệu cho người dùng 2.2 Cấp ủy quyền ngầm định Cấp ủy quyền ngầm định thường sử dụng cho ứng dụng điện thoại, đặc điểm ứng dụng sử dụng người chủ sở hữu điện thoại Ví dụ, bạn sử dụng điện thoại Android, thiết lập ban đầu bạn phải nhập vào tài khoản Google, tất ứng dụng tích hợp xác thực Google tự động xác thực bạn mà không cần phải thực lại bước cấp ủy quyền mã ủy quyền Refresh token không cần thiết cấp ủy quyền ngầm định Lược đồ cấp ủy quyền ngầm định sau: 11 Người dùng truy cập ứng dụng Ứng dụng gửi lại yêu cầu đăng nhập ứng dụng ủy quyền Người dùng nhập thông tin, đăng nhập ứng dụng Ứng dụng chuyển trang URL_CALLBACK kèm theo access Token Khi Người dùng đồng ý ứng dụng nhận access Token Ứng dụng gửi yêu cầu truy cập liệu kèm theo access Token lên máy chủ 12 liệu Sau xác nhận access Token với máy chủ ủy quyền, máy chủ liệu trả liệu cho ứng dụng ứng dụng lấy liệu, trả đăng nhập thành công cho nguwofi dùng 2.3 Cấp ủy quyền thông tin Người dùng Người dùng cung cấp thông tin bao gồm username password trực tiếp cho ứng dụng, ứng dụng dùng thơng tin u cầu máy chủ ủy quyền cấp access token Loại ủy quyền sử dụng ứng dụng người dùng tin tưởng hay ứng dụng thành phần hệ thống lớn máy chủ ủy quyền, máy chủ tài nguyên thành phần hệ thống 13 Ví dụ: Khi Instagram ứng dụng thuộc ứng dụng facebook Khi đăng nhập ứng dụng INnstagram sử dụng facebbok ta nhập username, password Facebook vào ứng dụng A, yêu cầu facebook cấp access Token URL có dạng sau: https://oauth.example.com/token? grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID Máy chủ ủy quyền kiểm tra thông tin người dùng với client_id ứng dụng Nếu khơng có vấn đề cho phép truy cập vào tài nguyên máy chủ xác thực 14 2.4: Cấp ủy quyền thông tin ứng dụng Cấp ủy quyền dùng ứng dụng cần truy nhập tài nguyên gọi phương thức từ máy chủ tài nguyên, tài nguyên không phụ thuộc vào người dùng xác định (tài nguyên dùng chung) V Vấn đề bảo mật 1.OAuth1.0 :  Một số phiên giao thức OAuth1(trừ 2-legged) biết bị lỗ hổng Session Fixation Lỗ hổng tồn luồng ủy quyền mã thông báo OAuth 15 Luồng hoạt động OAuth1.0 : o Người dùng bắt đầu luồng cách yêu cầu ứng dụng truy cập tài ngun Điều kích hoạt ứng dụng đưa request token đến nhà cung cấp ủy quyền o Người dùng đăng nhập vào nhà cung cấp cấp quyền truy cập vào ứng dụng o Sau cấp quyền truy cập , chuyển hướng trờ lại ứng dụng cho phép truy cập vào liệu tài nguyên nhà cung cấp Vấn đề khơng có đảm bảo bước thực người dùng Mặc dù ứng dụng sử dụng cookie công cụ quản lý phiên khác để đảm bảo bước bước cuối cùng người dùng khơng có cách để đảm bảo bước giống bước bước cuối Kịch công : o Kẻ công bắt đầu trình cách sử dụng tài khoản ứng dụng yêu cầu bắt đầu luồng OAuth o Ứng dụng có mã thơng báo u cầu chuyển hướng đến nhà cung cấp o Tại thời điểm này, kẻ công dừng lại ghi mã thông báo yêu cầu có URI-redirection o Kẻ cơng lừa nạn nhân truy cập liên kết ( URI ủy quyền từ redirection) Khi nạn nhân nhấn vào liên kết, họ gửi đến nhà cung cấp phép truy cập o Nạn nhân không nhận nên bắt đầu ứng dụng tiếp tục đăng nhập vào nhà cung cấp o Nhà cung cấp sau yêu cầu người dùng cấp quyền truy cập, xác định ứng dụng Nhưng người dùng cấp quyền truy cập, kẻ cơng thể xây dựng URI callback quay lại ứng dụng o Tại thời điểm này, tài khoản ứng dụng kẻ công liên kết với mã truy cập hợp lệ ủy quyền nạn nhân ủy quyền Tất kẻ cơng có tài khoản ứng dụng liên quan đến tài nguyên nạn nhân Các nhà cung cấp triển khai hỗ trợ callback theo số cách : o Cho phép callback Kẻ cơng cần thay đổi callback với điều kiện bước ủy quyền không ký cho phép kẻ công thay đổi tham số gọi lại Điều gửi người dùng đến trang kiểm soát kẻ 16      cơng, cho biết quay lại ứng dụng hồn thành cơng việc o Cho phép callback miền đăng ký trước Điều trở thành chạy đua việc đưa trở lại ứng dụng trước Bây , kẻ cơng khơng có cách biết xác người dùng cấp quyền truy cập, kẻ công thử nhiều lần thành công o Chỉ cho phép callback đăng ký tĩnh bỏ qua tham số Giống với điều o Không cho phép callback , yêu cầu người dùng tự hành động Nó tương tự điều 2, điều kiện đua trở nên dễ dàng nhiều khiến nạn nhân nhiều thời gian để quay lại ứng dụng.Ngồi trương hợp thủ cơng có xu hướng cho nhiều lần thử , ứng dụng đơn giản cố gắng trao đổi mã thông báo yêu cầu mã thông báo truy cập thất bại quyền truy cập người dùng ủy quyền nhà cung cấp không làm hiệu lực giao dịch lần thử thất bại, làm tăng mức độ tiếp xúc OAuth specification khơng mơ tả chế đảm bảo cho token bí mật khỏi kẻ nghe trộm chúng truyền từ Nhà cung cấp dịch vụ đến người dùng Khi sử dụng với chữ ký PLAINTEXT, giao thức OAuth không cố gắng bảo vệ thông tin đăng nhập người dùng khỏi kẻ trộm công man-inthe-middle.Nếu bảo vệ lớp vận chuyển không khả dụng không nên sử dụng phương thức chữ ký Mặc dù OAuth cung cấp chế để xác minh tính tồn vẹn u cầu , khơng đảm bảo tính bảo mật yêu cầu Oauth khơng cố gắng xác minh tính xác thực Nhà cung cấp dịch vụ Kẻ cơng lợi dụng điều cách chặn yêu cầu người dùng trả phản hồi sai lệch khơng xác Các nhà cung cấp dịch vụ nên xem xét công phát triển dịch vụ dựa OAuth nên yêu cầu bảo mật lớp vận chuyển cho yêu cầu tính xác thực Nhà cung cấp dịch vụ phản hổi yêu cầu vấn đề Nhà cung cấp dịch vụ phải bảo vệ kho lưu trữ thơng tin an tồn 17  Trong nhiều ứng dụng, ứng dụng người dùng chịu kiểm sốt bên có khả khơng tin cậy Nhà cung cấp dịch vụ không nên sử dụng consumer secret để xác minh danh tính mà cần yếu tố khác IP address  Phishing attack : Việc triển khai rộng rãi OAuth giao thức tương tự khiến người dùng bị ảnh hưởng đến việc thực chuyển hướng đến trang web nơi yêu cầu nhập mật khẩu.Nếu người dùng không cẩn thận xác minh tính xác thực trang web trước nhập thông tin đăng nhập họ, kẻ cơng khai thác thơng lệ để đánh cắp mật người dùng  Tấn cơng mật mã : SHA-1 , thuật tốn băm sử dụng HMACSHA1, chứng minh SHA-1 có số điểm yếu mật mã làm giảm đáng kể khả chống lại công va chạm  Giả mạo yêu cầu chéo trang (CSRF) : Là công dựa web Các cơng CSRF OAuth cho phép kẻ cơng có quyền tài ngun mà không cần đồng ý người dùng Tấn cơng CSRF vào URL Callback xảy  Nhà cung cấp dịch vụ muốn tự động xử lý yêu càu ủy quyền từ người dùng người dùng ủy quyền trước Nếu Comsumer Secret bị xâm phạm, sử lý tự động tạo thêm rủi ro bảo mật OAuth2.0  Phishing attack : Kẻ công tạo trang web giống hệt trang ủy quyền dịch vụ, thường chứa trường tên người dùng mật Sau thơng qua phương tiện khác nhau, kẻ cơng lừa người dùng truy cập trang trừ người dùng kiểm tra URL Người dùng nhập username + password  Tấn cơng “connect” request Kẻ cơng có quyền truy cập vào tài khoản nạn nhân Client cách kết nối tài khoản mình( Trên nhà cung cấp) Kịch công : o Kẻ công tạo tài khoản giả với số Nhà cung cấp o Kẻ cơng bắt đầu q trình “connect” với Client tài khoản giả Nhà cung cấp, dừng chuyển hướng , tức kẻ 18 công cấp cho Client quyền truy cập vào tài nguyên Nhà cung cấp Client chưa thông báo o Kẻ công tạo trang web đôc hại mô bước sau :  Đăng xuất người dùng Nhà cung cấp  Đăng nhập người dùng Nhà cung cấp với thông tin đăng nhập tài khoản giả  Giả mạo yêu cầu đến kết nối tài khoản Nhà cung cấp với Client Nên làm điều iframe để nạn nhân điều o Khi nạn nhân truy cập trang kẻ cơng Sau , “connect” request đưa dẫn đến tài khoản giả kẻ công kết nối với tài khoản nạn nhân Client.Lưu ý nạn nhân không yêu cầu cấp quyền truy cập cho khách hàng kẻ công ủy quyền bước  Hiện tại, để ngăn chặn kẻ công sử dụng redirect_uri tùy ý, nhiều máy chủ OAuth khớp phần tham số với redirect_uri quy định trước đăng ký máy khách Nói chung, q trình đăng ký, Client định tên miền Redirect_URI miền cụ thể phép Điều trở nên nguy hiểm kẻ cơng tìm thấy trang bị cơng kích để đánh cắp authorization_code Kịch công : o Kẻ cơng rị rỉ liệu (thơng qua XSS) từ trang client’s domain : https://client.com/vuln o Kẻ cơng tiêm mã Javascript trang gửi URL loaded trình duyệt ( với parameters fragments) cho kẻ công o Kẻ công tạo trang web lừa người dùng truy cập vào liên kết độc hai : https://provider.com/oauth/authorizr? client_id=CLIENT_ID&response_type=code&redirect_uri=https %3A%2F%2Fclient.com%2Fvuln o Khi nạn nhân tải liên kết này, user-agent chuyển hướng đên https://client.com/vuln?code=CODE CODE gửi đến kẻ công o Kẻ công sử dụng CODE để phát hành mã thông báo truy cập cách chuyển mã đến redirect_url xác thực, chẳng hạn https://client.com/oauth/callback?code=CODE 19 Cuộc cơng chí cịn nguy hiểm máy chủ ủy quyền hỗ trợ cấp ngầm Bằng cách vượt qua response_type=token, kẻ cơng đánh cắp mã thông báo trưc tiếp  CSRF Authorization Response Bằng cách thực cơng giả mạo trang web chéo, kẻ cơng liên kết tài khoản giả Nhà cung cấp với tài khoản nạn nhân Client ( Tấn công “connect” request) Cuộc công sử dụng yêu cầu thứ vủa chứng nhận mã thông báo ủy quyền Kịch công: o Kẻ công tạo tài khoản giả Nhà cung cấp o Kẻ cơng bắt đầu q trình “connect” cới Client tài khoản giả Nhà cung cấp, nhưng, dừng chuyển hướng đề cập yêu cầu Tức kẻ công cấp cho Client quyền truy cập vào tài ngun Client chưa thơng báo Kẻ công lưu mã ủy quyền o Kẻ công buộc nạn nhân phải yêu cầu : https://client.com//login?code=AUTH_CODE Điều dễ dàng thực cách khiến nạn nhân mở trang web độc hại thẻ img script có UR o Nếu nạn nhân đăng nhập vào Client, tài khoản giả kẻ công kết nối với tài khoản nạn nhân o Giờ đây, kẻ cơng đăng nhập vào tài khoản nạn nhân Client cách đăng nhập tài khoản giả nhà cung cấp OAuth2.0 cung cấp bảo mật chống lại công thơng qua state Nó hoạt động mã thông báo CSRF Kẻ công giả mại URL độc hại mà khơng biết state phiên người dùng cụ thể Tuy nhiên triển khai OAuth tại, tham số KHÔNG bắt buộc tùy chọn Các nhà phát triển không thành thạo bảo mật dễ bỏ qua điều  Sử dụng lại mã thông báo truy cập_ Một access_token OAuth 2.0 coi access_token độc lập với máy khách Tất đảm bảo access_token lưu trữ máy ủy quyền ánh xạ tới phạm vi thời gian hết hạn thích hợp Một mã thơng báo truy cập tạo cho client1 sử dụng chp lient Điều gây nguy hiểm cho khách hàng sẻ dụng Implicit grant Kịch công : 20 ... khái niệm Oauth, Cách thức hoạt động Oauth, so sánh Oauth với tảng khác sử dụng OpenID, … Xây dựng ứng dụng thử nghiệm có ứng dụng Oauth Mục lục Lời nói đầu I.Khái niệm Oauth ... cập ứng dụng Ứng dụng gửi lại yêu cầu đăng nhập ứng dụng ủy quyền Người dùng nhập thông tin, đăng nhập ứng dụng Ứng dụng chuyển trang URL_CALLBACK kèm theo access Token Khi Người dùng đồng ý ứng. .. ứng dụng 15 V.Vấn đề bảo Oauth 16 Oauth1 16 Oauth2 19 VI.So sánh Oauth chuẩn khác 1 .Oauth SSO 20 Oauth OpenID 21 Oauth1 .0 Oauth2 .0