Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Hướng dẫn này giúp bạn chọn sử dụng thư viện Dịch vụ nhận dạng của Google để uỷ quyền cho người dùng hoặc triển khai thư viện JavaScript của riêng bạn. Qua đó, bạn có thể quyết định quy trình uỷ quyền OAuth 2.0 nào phù hợp nhất với ứng dụng web của mình.
Thư viện GIS chạy trong các trình duyệt được hỗ trợ này trên thiết bị của người dùng. API này không nhằm sử dụng với các khung JavaScript phía máy chủ như Node.js, mà thay vào đó, hãy sử dụng thư viện ứng dụng Node.js của Google.
Hướng dẫn này chỉ đề cập đến các chủ đề về việc uỷ quyền và chia sẻ dữ liệu. Bài viết này không xem xét việc xác thực người dùng, thay vào đó, hãy xem hướng dẫn Đăng nhập bằng Google và Di chuyển từ tính năng đăng nhập bằng Google để người dùng đăng ký và đăng nhập.
Quyết định xem thư viện GIS có phù hợp với bạn không
Bạn phải chọn xem bạn nên sử dụng thư viện của Google hay tự tạo nội dung phù hợp nhất với nhu cầu của mình. Tổng quan về các tính năng và chức năng:
Thư viện JavaScript của Dịch vụ danh tính của Google triển khai:
Quy trình lấy sự đồng ý dựa trên cửa sổ bật lên giúp giảm thiểu các lệnh chuyển hướng, từ đó cho phép người dùng ở lại trang web của bạn trong suốt quá trình cho phép.
Các tính năng bảo mật như Giả mạo yêu cầu trên nhiều trang web (CRSF).
Các phương thức trợ giúp để yêu cầu từng phạm vi và xác nhận sự đồng ý của người dùng.
Các đường liên kết đến tài liệu và khả năng xử lý lỗi mà con người có thể sử dụng trong quá trình phát triển và sau này cho khách truy cập trang web của bạn sử dụng.
Khi triển khai mà không có thư viện Dịch vụ danh tính, bạn chịu trách nhiệm về:
Quản lý các yêu cầu và phản hồi bằng điểm cuối OAuth 2.0 của Google, bao gồm cả các lượt chuyển hướng.
Tối ưu hoá trải nghiệm người dùng.
Triển khai các tính năng bảo mật để xác thực các yêu cầu, phản hồi và để ngăn chặn CSRF.
Các phương thức để xác nhận người dùng đã đồng ý cho bất kỳ phạm vi nào được yêu cầu.
Quản lý mã lỗi OAuth 2.0, tạo thông báo mà con người có thể đọc được và đường liên kết tới phần trợ giúp của người dùng.
Tóm lại, Google cung cấp thư viện GIS để giúp bạn triển khai ứng dụng OAuth 2.0 một cách nhanh chóng và an toàn, đồng thời tối ưu hoá trải nghiệm uỷ quyền của người dùng.
Chọn quy trình uỷ quyền
Bạn sẽ cần chọn một trong hai quy trình uỷ quyền OAuth 2.0: ngầm định hoặc mã uỷ quyền – bất kể bạn quyết định sử dụng thư viện JavaScript của Dịch vụ Google Identity hay tạo thư viện riêng.
Cả hai quy trình đều tạo ra một mã truy cập. Bạn có thể dùng mã này để gọi các API của Google.
Điểm khác biệt chính giữa hai quy trình này là:
số lượng hành động của người dùng,
việc ứng dụng của bạn có gọi API Google khi không có người dùng hay không,
liệu cần có một nền tảng phụ trợ để lưu trữ điểm cuối và lưu trữ mã làm mới cho mỗi người dùng
đối với tài khoản người dùng cá nhân, và
mức độ bảo mật người dùng cao hơn hoặc thấp hơn.
Khi so sánh các luồng và đánh giá các yêu cầu về bảo mật, một yếu tố cần cân nhắc là mức độ bảo mật người dùng sẽ thay đổi tuỳ theo phạm vi mà bạn chọn. Ví dụ: việc xem lời mời trên lịch ở chế độ chỉ đọc có thể ít rủi ro hơn so với việc sử dụng phạm vi đọc/ghi để chỉnh sửa tệp trong Drive.
So sánh quy trình OAuth 2.0
Luồng ngầm ẩn
Quy trình mã uỷ quyền
Cần có sự đồng ý của người dùng
Đối với mọi yêu cầu về mã thông báo, bao gồm cả việc thay thế mã thông báo đã hết hạn.
Chỉ dành cho yêu cầu mã thông báo đầu tiên.
Người dùng phải có mặt
Có
Không, hỗ trợ sử dụng ngoại tuyến.
Bảo mật người dùng
Ít gặp nhất
Hầu hết, chế độ này có xác thực ứng dụng khách và tránh rủi ro xử lý mã thông báo trong trình duyệt.
Đã cấp mã truy cập
Có
Có
Đã phát hành mã làm mới
Không
Có
Cần có trình duyệt được hỗ trợ
Có
Có
Mã truy cập dùng để gọi các API của Google
chỉ từ ứng dụng web chạy trong trình duyệt của người dùng.
từ một máy chủ chạy trên nền tảng phụ trợ hoặc từ một ứng dụng web chạy trong trình duyệt của người dùng.
Cần có nền tảng phụ trợ
Không
Có, để lưu trữ và lưu trữ thiết bị đầu cuối.
Cần bộ nhớ an toàn
Không
Có, để lưu trữ mã thông báo làm mới.
Yêu cầu lưu trữ điểm cuối của mã uỷ quyền
Không
Có, để nhận mã uỷ quyền từ Google.
Hành vi hết hạn của mã truy cập
Người dùng cần thực hiện một cử chỉ như nhấn nút hoặc nhấp vào đường liên kết để yêu cầu và nhận mã truy cập mới, hợp lệ.
Sau yêu cầu ban đầu của người dùng, nền tảng của bạn sẽ trao đổi mã làm mới đã lưu trữ để lấy một mã truy cập mới, hợp lệ cần thiết để gọi các API của Google.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 2023-12-01 UTC."],[[["\u003cp\u003eThis guide helps developers choose between Google Identity Services or a custom JavaScript library for OAuth 2.0 authorization in their web applications.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Identity Services offers pre-built security features, optimized user experience, and easier implementation compared to building a custom solution.\u003c/p\u003e\n"],["\u003cp\u003eDevelopers need to select between the Implicit or Authorization Code flow based on security, user presence requirements, and backend needs.\u003c/p\u003e\n"],["\u003cp\u003eAuthorization Code flow is recommended for enhanced security, offline access, and refresh token management through a backend server.\u003c/p\u003e\n"],["\u003cp\u003eThe guide assumes prior knowledge of OAuth 2.0 concepts and focuses solely on authorization and data sharing, not user authentication.\u003c/p\u003e\n"]]],[],null,["# Choose a user authorization model\n\nThis guide helps you to choose between using the Google Identity Services\nlibrary for user authorization or implementing your own JavaScript library. It\nhelps you decide which OAuth 2.0 authorization flow is best for your web\napplication.\n\nPrior to reading this guide it is assumed that you are familiar with the terms\nand concepts described in the [Overview](/identity/oauth2/web/guides/overview) and\n[How user authorization works](/identity/oauth2/web/guides/how-user-authz-works) guide.\n\nThe GIS library runs in these [supported browsers](/identity/gsi/web/guides/supported-browsers) on the user's device. It\nis not intended for use with server-side JavaScript frameworks such as Node.js,\ninstead use Google's [Node.js](https://github.com/googleapis/google-api-nodejs-client)\nclient library.\n\nThis guide only covers authorization and data sharing topics. It does not review\nuser authentication, instead see [Sign In With Google](/identity/gsi/web) and the [Migrating\nfrom Google Sign-In](/identity/gsi/web/guides/migration) guide for user sign-up and sign-in.\n\nDeciding if the GIS library is right for you\n--------------------------------------------\n\nYou must choose if using Google's library, or creating your own best fits your\nneeds. An overview of features and functionality:\n\n- Google's Identity Services JavaScript library implements:\n - Popup based consent flows to minimize redirects, thus enabling users to remain on your site throughout the authorization process.\n - Security features such as Cross-site Request Forgery (CRSF).\n - Helper methods to request individual scopes and confirm user consent.\n - Human friendly error handling and documentation links for use by engineers during development and later for visitors to your site.\n- When implementing without the Identity Services library you are responsible for:\n - Managing requests and responses with Google's OAuth 2.0 endpoints, including redirects.\n - Optimizing the user experience.\n - Implementation of security features to validate requests, responses, and to prevent CSRF.\n - Methods to confirm a user has granted consent for any requested scopes.\n - Managing OAuth 2.0 error codes, creating human readable messages, and links to user help.\n\nIn summary, Google offers the GIS library to help you to quickly, and securely\nimplement an OAuth 2.0 client and optimize the user's authorization experience.\n\nChoosing an authorization flow\n------------------------------\n\nYou will need to choose one of two OAuth 2.0 authorization flows: implicit or\nauthorization code -- regardless if you decide to use the Google Identity\nServices JavaScript library or to create your own library.\n\nBoth flows result in an access token which can be used to call Google APIs.\n\nThe primary differences between the two flows are:\n\n- the number of user actions,\n- whether your app will call Google APIs without the user present,\n- if a backend platform is needed to host an endpoint and to store per-user refresh tokens for individual user accounts, and\n- higher or lower levels of user security.\n\nWhen comparing flows and evaluating your security requirements, a factor to\nconsider is that the level of user security varies depending on the scopes you\nchoose. For example, viewing calendar invites as read-only might be considered\nless risky than using a read/write scope to edit files in Drive.\n| **Key Point:** Authorization code flow is recommended because it provides a more secure flow.\n\nOAuth 2.0 flow comparison\n-------------------------\n\n|--------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------|\n| | **Implicit flow** | **Authorization code flow** |\n| **User consent required** | For every token request, including replacing expired tokens. | Only for the first token request. |\n| **User must be present** | Yes | No, supports offline use. |\n| **User security** | Least | Most, has client authentication and avoids in-browser token handling risks. |\n| **Access token issued** | Yes | Yes |\n| **Refresh token issued** | No | Yes |\n| **Supported browser required** | Yes | Yes |\n| **Access token used to call Google APIs** | only from a web app running in the user's browser. | either from a server running on backend platform, or from a web app running in the user's browser. |\n| **Requires backend platform** | No | Yes, for endpoint hosting and storage. |\n| **Secure storage needed** | No | Yes, for refresh token storage. |\n| **Requires hosting of an authorization code endpoint** | No | Yes, to receive authorization codes from Google. |\n| **Access token expiration behavior** | A user gesture such as button press or clicking on a link is required to request and obtain a new, valid access token. | After an initial user request, your platform exchanges the stored refresh token to obtain a new, valid access token necessary to call Google APIs. |"]]
