Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Bu kılavuz, kullanıcı yetkilendirme için Google Kimlik Hizmetleri kitaplığını kullanma veya kendi JavaScript kitaplığınızı uygulama arasında seçim yapmanıza yardımcı olur. Web uygulamanız için hangi OAuth 2.0 yetkilendirme akışının en iyisi olduğuna karar vermenize yardımcı olur.
Coğrafi Bilgi Sistemi kitaplığı, kullanıcının cihazında, desteklenen tarayıcılarda çalışır. Node.js gibi sunucu tarafı JavaScript çerçeveleriyle kullanılmak üzere tasarlanmamıştır. Bunun yerine Google'ın Node.js istemci kitaplığını kullanır.
Bu kılavuz yalnızca yetkilendirme ve veri paylaşımı konularını kapsar. Kullanıcı kimlik doğrulamasını incelemez. Bunun yerine Google ile Oturum Açma sayfasına ve kullanıcı kaydı ve oturum açma işlemleri için Google ile Oturum Açma rehberine bakın.
Coğrafi Bilgi Sistemi kitaplığının sizin için uygun olup olmadığına karar verme
Google'ın kitaplığını kullanmayı veya ihtiyaçlarınıza en uygun şekilde kendi kitaplığınızı oluşturmayı seçmelisiniz. Özelliklere ve işlevlere genel bakış:
Yönlendirmeleri en aza indirerek kullanıcıların yetkilendirme işlemi boyunca sitenizde kalmasını sağlayan pop-up tabanlı izin akışları.
Siteler Arası İstek Sahtekarlığı (CRSF) gibi güvenlik özellikleri.
Bağımsız kapsamlar istemek ve kullanıcı izinlerini onaylamak için yardımcı yöntemler.
İnsan dostu hata işleme ve dokümantasyon bağlantıları, geliştirme sırasında mühendisler tarafından ve daha sonra sitenizin ziyaretçileri için kullanılabilir.
Kimlik Hizmetleri kitaplığı olmadan uygulama yaptığınızda aşağıdakilerden sorumlu olursunuz:
Yönlendirmeler dahil olmak üzere istekleri ve yanıtları Google'ın OAuth 2.0 uç noktalarıyla yönetme.
Kullanıcı deneyimini optimize etmek.
İstekleri ve yanıtları doğrulamak ve CSRF'yi önlemek için güvenlik özelliklerinin uygulanması.
Kullanıcının istenen kapsamlar için izin verdiğini onaylama yöntemleri.
OAuth 2.0 hata kodlarını yönetme, okunabilir mesajlar oluşturma ve kullanıcı yardımı bağlantıları oluşturma.
Özetle Google, bir OAuth 2.0 istemcisini hızlı ve güvenli bir şekilde uygulamanıza ve kullanıcının yetkilendirme deneyimini optimize etmenize yardımcı olmak için Coğrafi Bilgi Sistemi kitaplığı sunar.
Yetkilendirme akışı seçme
Google Kimlik Hizmetleri JavaScript kitaplığını kullanmaya veya kendi kitaplığınızı oluşturmaya karar vermeniz fark etmeksizin, iki OAuth 2.0 yetkilendirme akışından birini seçmeniz gerekir: örtülü veya yetkilendirme kodu.
Her iki akış da Google API'lerini çağırmak için kullanılabilecek bir erişim jetonuyla sonuçlanır.
İki akış arasındaki temel farklar şunlardır:
kullanıcı işlemlerinin sayısı,
Uygulamanızın kullanıcı olmadan Google API'lerini çağırıp çağırmayacağını,
uç nokta barındırmak ve bağımsız kullanıcı hesapları için kullanıcı başına yenileme jetonlarını depolamak üzere bir arka uç platformu gerekirse ve
daha yüksek veya daha düşük kullanıcı güvenliği düzeyleri.
Akışları karşılaştırırken ve güvenlik gereksinimlerinizi değerlendirirken, kullanıcı güvenliği düzeyinin seçtiğiniz kapsamlara bağlı olarak değişiklik gösterdiğini göz önünde bulundurmanız gerekir. Örneğin, takvim davetlerini salt okunur olarak görüntülemek, Drive'daki dosyaları düzenlemek için okuma/yazma kapsamı kullanmaktan daha az riskli olabilir.
OAuth 2.0 akış karşılaştırması
Dolaylı akış
Yetkilendirme kodu akışı
Kullanıcı izni gerekli
Süresi dolmuş jetonların değiştirilmesi de dahil olmak üzere her jeton isteği için.
Yalnızca ilk jeton isteği için.
Kullanıcı mevcut olmalıdır
Evet
Hayır, çevrimdışı kullanımı destekler.
Kullanıcı güvenliği
En seyrek
Çoğu, istemci kimlik doğrulamasına sahiptir ve tarayıcı içi jeton işleme risklerini önler.
Erişim jetonu verildi
Evet
Evet
Yenileme jetonu verildi
Hayır
Evet
Desteklenen tarayıcı gerekir
Evet
Evet
Google API'lerini çağırmak için kullanılan erişim jetonu
yalnızca kullanıcının tarayıcısında çalışan bir web uygulamasından.
arka uç platformunda çalışan bir sunucudan veya kullanıcının tarayıcısında çalışan bir web uygulamasından.
Arka uç platformu gerektirir
Hayır
Evet, uç nokta barındırma ve depolama alanı için.
Güvenli depolama alanı gerekli
Hayır
Evet, yenileme jetonu depolaması için.
Yetkilendirme kodu uç noktasının barındırılmasını gerektirir
Hayır
Evet, Google'dan yetkilendirme kodları almak için.
Erişim jetonunun sona erme davranışı
Yeni ve geçerli bir erişim jetonu istemek ve almak için düğmeye basmak veya bağlantıyı tıklamak gibi bir kullanıcı hareketi gerekir.
İlk kullanıcı isteğinden sonra platformunuz, Google API'lerini çağırmak için gereken yeni ve geçerli bir erişim jetonu almak için depolanan yenileme jetonunu değiştirir.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 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. |"]]
