Masaüstü Uygulamaları için OAuth 2.0

Bu dokümanda, masaüstü uygulamalarının (ör. Windows, macOS veya Linux'ta çalışan uygulamalar ya da komut satırı arayüzü (CLI) araçları) Google API'lerine erişim yetkisi vermek için Google'ın OAuth 2.0 uç noktalarını nasıl kullandığı açıklanmaktadır.

OAuth 2.0 sayesinde kullanıcılar, bir uygulamayla belirli verileri paylaşırken kullanıcı adlarını, şifrelerini ve diğer bilgilerini gizli tutabilir. Örneğin, bir uygulama, kullanıcıların Google Drive'larında dosya depolamak için kullanıcılardan izin almak üzere OAuth 2.0'ı kullanabilir.

Masaüstü uygulamaları, kullanıcının makinesine yerel olarak yüklenir (ör. bağımsız masaüstü yazılımları, geliştirici CLI araçları, arka plan senkronizasyon yardımcı programları veya komut dosyaları). Bu uygulamalar ayrı ayrı cihazlara dağıtıldığından, gizli bilgileri saklayamayacakları varsayılır (herkese açık istemcilerdir). Kullanıcı uygulamayla aktif olarak etkileşimde bulunurken veya uygulama arka planda çalışırken Google API'lerine erişebilirler.

Bu yetkilendirme akışı, web sunucusu uygulamaları için kullanılana benzer. Temel fark, masaüstü uygulamalarının sistem tarayıcısını açması ve Google'ın yetkilendirme sunucusundan gelen yanıtları işlemek için yerel bir yönlendirme URI'si (ör. loopback IP adresi) sağlaması gerekmesidir.

Kitaplıklar ve örnekler

Masaüstü uygulamaları için OAuth 2.0'ı uygularken programlama diliniz (ör. Python, Java, Node.js, Go, .NET) için Google API istemci kitaplıklarını kullanmanızı öneririz. İstemci kitaplıkları, kullanıcı yetkilendirmesini ve jeton yönetimini işleyerek uygulamayı daha basit ve alt düzey HTTP/REST uç noktalarını doğrudan kullanmaya kıyasla daha az hataya açık hale getirir.

Mobil uygulamalar için Android ve iOS yetkilendirme kılavuzlarına bakın.

Sistem tarayıcısını desteklemeyen veya giriş özellikleri sınırlı olan cihazlarda (ör. TV'ler, oyun konsolları, kameralar veya yazıcılar) çalışan uygulamalar için TV'ler ve Cihazlar için OAuth 2.0 veya TV'lerde ve Giriş Özellikleri Sınırlı Olan Cihazlarda Oturum Açma başlıklı makaleyi inceleyin.

Ön koşullar

Projeniz için API'leri etkinleştirme

Google API'lerini çağıran tüm uygulamaların, API Konsolu'nda bu API'leri etkinleştirmesi gerekir.

Projeniz için bir API'yi etkinleştirmek üzere:

  1. Google API Konsolu'nda API Kitaplığı'nı açın.
  2. İstenirse bir proje seçin veya yeni bir proje oluşturun.
  3. API Kitaplığı, mevcut tüm API'leri ürün ailesine ve popülerliğe göre gruplandırarak listeler. Etkinleştirmek istediğiniz API listede görünmüyorsa arama yaparak bulun veya ait olduğu ürün ailesinde Tümünü Görüntüle'yi tıklayın.
  4. Etkinleştirmek istediğiniz API'yi seçin, ardından Etkinleştir düğmesini tıklayın.
  5. İstenirse faturalandırmayı etkinleştirin.
  6. İstenirse API'nin Hizmet Şartları'nı okuyup kabul edin.

Yetkilendirme kimlik bilgileri oluşturma

Google API'lerine erişmek için OAuth 2.0 kullanan tüm uygulamaların, uygulamayı Google'ın OAuth 2.0 sunucusuna tanımlayan yetkilendirme kimlik bilgilerine sahip olması gerekir. Aşağıdaki adımlarda, projeniz için nasıl kimlik bilgileri oluşturacağınız açıklanmaktadır. Uygulamalarınız, bu kimlik bilgilerini kullanarak ilgili proje için etkinleştirdiğiniz API'lere erişebilir.

  1. Müşteriler sayfasına gidin.
  2. Create client'ı (İstemci oluştur) tıklayın.
  3. Masaüstü uygulaması uygulama türünü seçin.
  4. Ad alanına OAuth istemcisi için bir ad girin. Bu ad, istemciyi tanımlamak için projenizin İstemciler sayfasında gösterilir.
  5. Oluştur'u tıklayın.

İstemci kimliğiniz ve istemci gizli anahtarınız oluşturulur ve Google Cloud Console'da gösterilir. Masaüstü uygulamaları herkese açık istemcilerdir ve gizli anahtarları gizli tutamaz. Yetkilendirme kodları isterken her zaman PKCE (Kod Değişimi İçin Doğrulama Anahtarı) kullanın.

Erişim kapsamlarını belirleme

Kapsamlar, uygulamanızın yalnızca ihtiyaç duyduğu kaynaklara erişim istemesini sağlarken kullanıcıların da uygulamanıza verdikleri erişim miktarını kontrol etmelerine olanak tanır. Bu nedenle, istenen kapsam sayısı ile kullanıcı rızası alma olasılığı arasında ters bir ilişki olabilir.

OAuth 2.0 yetkilendirmesini uygulamaya başlamadan önce uygulamanızın erişim izni gerektirecek kapsamları belirlemenizi öneririz.

OAuth 2.0 API Kapsamları dokümanında, Google API'lerine erişmek için kullanabileceğiniz kapsamların tam listesi yer alır.

OAuth 2.0 erişim jetonları alma

Aşağıdaki adımlarda, uygulamanızın kullanıcı adına API isteği gerçekleştirmek için kullanıcının iznini almak üzere Google'ın OAuth 2.0 sunucusuyla nasıl etkileşim kurduğu gösterilmektedir. Uygulamanızın, kullanıcı yetkilendirmesi gerektiren bir Google API isteğini yürütebilmesi için bu izne sahip olması gerekir.

1. adım: Kod doğrulayıcı ve sorgu oluşturun

Google, yüklü uygulama akışını daha güvenli hale getirmek için Kod Değişimi İçin Doğrulama Anahtarı (PKCE) protokolünü destekler. Her yetkilendirme isteği için benzersiz bir kod doğrulayıcı oluşturulur ve "code_challenge" adı verilen dönüştürülmüş değeri, yetkilendirme kodunu almak için yetkilendirme sunucusuna gönderilir.

Kod doğrulayıcıyı oluşturma

code_verifier, ayrılmamış karakterleri [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" kullanan, minimum 43 karakter ve maksimum 128 karakter uzunluğunda, yüksek entropili bir kriptografik rastgele dizedir.

Kod doğrulayıcı, değerin tahmin edilmesini imkansız kılacak kadar entropiye sahip olmalıdır.

Kod doğrulamasını oluşturma

Kod sorgusu oluşturmanın iki yöntemi desteklenir.

Kod Sınaması Oluşturma Yöntemleri
S256 (önerilen) Kod sorgulaması, kod doğrulayıcının Base64URL (doldurma olmadan) kodlamalı SHA256 karmasıdır.
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
plain Kod sorgulaması, yukarıda oluşturulan kod doğrulayıcı ile aynı değere sahiptir.
code_challenge = code_verifier

2. adım: Google'ın OAuth 2.0 sunucusuna istek gönderin

Kullanıcı yetkilendirmesi almak için https://accounts.google.com/o/oauth2/v2/auth adresindeki Google'ın yetkilendirme sunucusuna bir istek gönderin. Bu uç nokta, etkin oturum aramayı yönetir, kullanıcının kimliğini doğrular ve kullanıcı rızasını alır. Uç noktaya yalnızca SSL üzerinden erişilebilir ve HTTP (SSL olmayan) bağlantıları reddeder.

Yetkilendirme sunucusu, yüklü uygulamalar için aşağıdaki sorgu dizesi parametrelerini destekler:

Parametreler
client_id Zorunlu

Uygulamanızın istemci kimliği. Bu değeri Cloud Console'daki İstemciler sayfasında bulabilirsiniz.

redirect_uri Zorunlu

Google'ın yetkilendirme sunucusunun uygulamanıza nasıl yanıt göndereceğini belirler. Yüklü uygulamalar için çeşitli yönlendirme seçenekleri vardır. Yetkilendirme kimlik bilgilerinizi belirli bir yönlendirme yöntemini göz önünde bulundurarak ayarlamanız gerekir.

Değer, istemcinizin Cloud Console İstemciler sayfasında yapılandırdığınız OAuth 2.0 istemcisinin yetkili yönlendirme URI'larından biriyle tam olarak eşleşmelidir. Bu değer yetkili bir URI ile eşleşmezse redirect_uri_mismatch hatası alırsınız.

Tabloda, her yöntem için uygun redirect_uri parametre değeri gösterilmektedir:

redirect_uri değerleri
Özel URI şeması com.example.app:redirect_uri_path

veya

com.googleusercontent.apps.123:redirect_uri_path
  • com.example.app, kontrolünüz altındaki bir alanın ters DNS gösterimidir. Özel şemanın geçerli olması için nokta içermesi gerekir.
  • com.googleusercontent.apps.123, istemci kimliğinin ters DNS gösterimidir.
  • redirect_uri_path, /oauth2redirect gibi isteğe bağlı bir yol bileşenidir. Yolun tek bir eğik çizgiyle başlaması gerektiğini unutmayın. Bu, normal HTTP URL'lerinden farklıdır.
Loopback IP adresi http://127.0.0.1:port veya http://[::1]:port

Platformunuzu ilgili loopback IP adresi için sorgulayın ve rastgele bir kullanılabilir bağlantı noktasında HTTP dinleyicisi başlatın. port yerine uygulamanızın dinlediği gerçek bağlantı noktası numarasını yazın.

Mobil uygulamalarda loopback IP adresi yönlendirme seçeneği desteğinin KULLANIMDAN KALDIRILDIĞINI unutmayın.

response_type Zorunlu

Google OAuth 2.0 uç noktasının bir yetkilendirme kodu döndürüp döndürmeyeceğini belirler.

Yüklü uygulamalar için parametre değerini code olarak ayarlayın.

scope Zorunlu

Uygulamanızın kullanıcı adına erişebileceği kaynakları tanımlayan, boşlukla ayrılmış kapsam listesi. Bu değerler, Google'ın kullanıcıya gösterdiği kullanıcı rızası ekranını bilgilendirir.

Kapsamlar, uygulamanızın yalnızca ihtiyaç duyduğu kaynaklara erişim isteğinde bulunmasını sağlarken kullanıcıların da uygulamanıza verdikleri erişim miktarını kontrol etmelerine olanak tanır. Bu nedenle, istenen kapsam sayısı ile kullanıcı rızası alma olasılığı arasında ters bir ilişki vardır.

code_challenge Önerilen

Yetkilendirme kodu değişimi sırasında sunucu tarafı sorgulaması olarak kullanılacak kodlanmış bir code_verifier belirtir. Daha fazla bilgi için kod sorgulaması oluşturma bölümüne bakın.

code_challenge_method Önerilen

Yetkilendirme kodu değişimi sırasında kullanılacak code_verifier kodlamasında hangi yöntemin kullanıldığını belirtir. Bu parametre, code_challenge parametresiyle birlikte kullanılmalıdır. code_challenge içeren istekte code_challenge_method değeri yoksa varsayılan olarak plain kullanılır. Bu parametre için desteklenen tek değerler S256 veya plain değerleridir.

state Önerilen

Uygulamanızın, yetkilendirme isteğiniz ile yetkilendirme sunucusunun yanıtı arasındaki durumu korumak için kullandığı dize değerini belirtir. Sunucu, kullanıcı uygulamanızın erişim isteğini kabul ettikten veya reddettikten sonra redirect_uri URL parça tanımlayıcısında (#) name=value çifti olarak gönderdiğiniz tam değeri döndürür.

Bu parametreyi, kullanıcıyı uygulamanızdaki doğru kaynağa yönlendirme, tek seferlik rastgele sayılar gönderme ve siteler arası istek sahteciliğini azaltma gibi çeşitli amaçlarla kullanabilirsiniz. redirect_uri tahmin edilebileceğinden, state değeri kullanmak gelen bir bağlantının kimlik doğrulama isteğinin sonucu olduğuna dair güvencenizi artırabilir. Rastgele bir dize oluşturursanız veya bir çerezin ya da istemcinin durumunu yakalayan başka bir değerin karmasını kodlarsanız isteğin ve yanıtın aynı tarayıcıdan geldiğinden emin olmak için yanıtı doğrulayabilirsiniz. Bu, siteler arası istek sahteciliği gibi saldırılara karşı koruma sağlar. state jetonunun nasıl oluşturulacağı ve onaylanacağıyla ilgili bir örnek için OpenID Connect belgelerine bakın.

login_hint İsteğe bağlı

Uygulamanız, hangi kullanıcının kimlik doğrulaması yapmaya çalıştığını biliyorsa Google Kimlik Doğrulama Sunucusu'na ipucu sağlamak için bu parametreyi kullanabilir. Sunucu, oturum açma formundaki e-posta alanını önceden doldurarak veya uygun çoklu giriş oturumunu seçerek giriş akışını basitleştirmek için ipucunu kullanır.

Parametre değerini, kullanıcının Google kimliğine eşdeğer bir e-posta adresi veya sub tanımlayıcısı olarak ayarlayın.

Örnek yetkilendirme URL'leri

Aşağıdaki sekmelerde, farklı yönlendirme URI'si seçenekleri için örnek yetkilendirme URL'leri gösterilmektedir.

URL'ler, redirect_uri parametresinin değeri dışında aynıdır. URL'ler ayrıca zorunlu response_type ve client_id parametrelerinin yanı sıra isteğe bağlı state parametresini de içerir. Her URL, okunabilirliği artırmak için satır sonları ve boşluklar içerir.

Özel URI şeması

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=com.example.app%3A/oauth2redirect&
 client_id=client_id

Geri döngü IP adresi

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=http%3A//127.0.0.1%3A9004&
 client_id=client_id

3. adım: Google, kullanıcıdan izin ister

Bu adımda kullanıcı, uygulamanıza istenen erişimi verip vermeyeceğine karar verir. Bu aşamada Google, uygulamanızın adını ve kullanıcının yetkilendirme kimlik bilgileriyle erişim izni istediği Google API'leri hizmetlerini gösteren bir izin penceresi ve verilecek erişim kapsamlarının özetini gösterir. Kullanıcı, uygulamanızın istediği bir veya daha fazla kapsama erişim izni vermeyi kabul edebilir ya da isteği reddedebilir.

Uygulamanızın bu aşamada herhangi bir işlem yapması gerekmez. Google'ın OAuth 2.0 sunucusundan erişim izni verilip verilmediğini belirten yanıtı bekler. Bu yanıt, bir sonraki adımda açıklanmıştır.

Hatalar

Google'ın OAuth 2.0 yetkilendirme uç noktasına gönderilen istekler, beklenen kimlik doğrulama ve yetkilendirme akışları yerine kullanıcılara yönelik hata mesajları gösterebilir. Sık karşılaşılan hata kodları ve önerilen çözümler şunlardır:

admin_policy_enforced

Google Hesabı, Google Workspace yöneticisinin politikaları nedeniyle istenen bir veya daha fazla kapsamı yetkilendiremiyor. Yöneticilerin, OAuth istemci kimliğinize açıkça erişim izni verilene kadar tüm kapsamlara veya hassas ve kısıtlanmış kapsamlara erişimi nasıl kısıtlayabileceği hakkında daha fazla bilgi için Google Workspace verilerine hangi üçüncü taraf uygulamalar ve dahili uygulamaların erişebileceğini yönetme başlıklı Google Workspace Yönetici Yardım makalesini inceleyin.

disallowed_useragent

Yetkilendirme uç noktası, Google'ın OAuth 2.0 Politikaları tarafından izin verilmeyen yerleşik bir kullanıcı aracısı içinde gösteriliyor.

iOS ve macOS geliştiricileri, WKWebView uygulamasında yetkilendirme isteklerini açarken bu hatayla karşılaşabilir. Geliştiriciler bunun yerine iOS için Google ile Oturum Açma veya OpenID Foundation'ın iOS için AppAuth gibi iOS kitaplıklarını kullanmalıdır.

Web geliştiricileri, bir iOS veya macOS uygulaması yerleşik bir kullanıcı aracısında genel bir web bağlantısı açtığında ve kullanıcı sitenizden Google'ın OAuth 2.0 yetkilendirme uç noktasına gittiğinde bu hatayla karşılaşabilir. Geliştiriciler, genel bağlantıların işletim sisteminin varsayılan bağlantı işleyicisinde açılmasına izin vermelidir. Bu işleyiciler arasında hem Geçiş Bağlantıları işleyicileri hem de varsayılan tarayıcı uygulaması yer alır. SFSafariViewController kitaplığı da desteklenen bir seçenektir.

org_internal

İstekteki OAuth istemci kimliği, belirli bir Google Cloud kuruluşundaki Google Hesaplarına erişimi sınırlayan bir projenin parçasıdır. Bu yapılandırma seçeneği hakkında daha fazla bilgi için OAuth kullanıcı rızası ekranınızı ayarlama yardım makalesindeki Kullanıcı türü bölümüne bakın.

deleted_client

İsteği göndermek için kullanılan OAuth istemcisi silinmiştir. Silme işlemi manuel olarak veya kullanılmayan istemciler söz konusu olduğunda otomatik olarak yapılabilir. Silinen müşteriler, silme işleminden sonraki 30 gün içinde geri yüklenebilir. Daha fazla bilgi edinin .

invalid_grant

Kod doğrulayıcı ve sınama kullanıyorsanız code_callenge parametresi geçersiz veya eksiktir. code_challenge parametresinin doğru şekilde ayarlandığından emin olun.

Erişim jetonu yenilenirken jetonun süresi dolmuş veya jeton geçersiz kılınmış olabilir. Kullanıcının kimliğini tekrar doğrulayın ve yeni jetonlar almak için kullanıcıdan izin isteyin. Bu hatayı görmeye devam ederseniz uygulamanızın doğru şekilde yapılandırıldığından ve isteğinizde doğru jetonları ve parametreleri kullandığınızdan emin olun. Aksi takdirde, kullanıcı hesabı silinmiş veya devre dışı bırakılmış olabilir.

redirect_uri_mismatch

Yetkilendirme isteğinde iletilen redirect_uri, OAuth istemci kimliği için yetkilendirilmiş bir yönlendirme URI'siyle eşleşmiyor. Google Cloud Console'un İstemciler sayfasında yetkilendirilmiş yönlendirme URI'lerini inceleyin.

Geçirilen redirect_uri, istemci türü için geçersiz olabilir.

redirect_uri parametresi, kullanımdan kaldırılan ve artık desteklenmeyen OAuth bant dışı (OOB) akışına başvuruyor olabilir. Entegrasyonunuzu güncellemek için geçiş rehberini inceleyin.

invalid_request

İsteğinizle ilgili bir sorun oluştu. Bunun birkaç nedeni olabilir:

  • İstek doğru şekilde biçimlendirilmemiş.
  • İstekte gerekli parametreler eksikti.
  • İstek, Google'ın desteklemediği bir yetkilendirme yöntemi kullanıyor. OAuth entegrasyonunuzun önerilen bir entegrasyon yöntemi kullandığını doğrulayın.
  • Yönlendirme URI'si için desteklenmeyen bir özel şema kullanıldı. Özel URI şeması, Android veya Chrome uygulamalarında desteklenmiyor hata mesajını görürseniz özel URI şeması alternatifleri hakkında daha fazla bilgi edinin.

4. adım: OAuth 2.0 sunucu yanıtını işleme

Uygulamanızın yetkilendirme yanıtını alma şekli, kullandığı yönlendirme URI şemasına bağlıdır. Şemadan bağımsız olarak yanıt, bir yetkilendirme kodu (code) veya hata (error) içerir. Örneğin, error=access_denied, kullanıcının isteği reddettiğini gösterir.

Kullanıcı uygulamanıza erişim izni verirse bir sonraki adımda açıklandığı gibi yetkilendirme kodunu bir erişim jetonu ve yenileme jetonu ile değiştirebilirsiniz.

5. adım: Yenileme ve erişim jetonları için yetkilendirme kodu değiş tokuşu yapın

Bir yetkilendirme kodunu erişim jetonuyla değiştirmek için https://oauth2.googleapis.com/token uç noktasını çağırın ve aşağıdaki parametreleri ayarlayın:

Alanlar
client_id Cloud Console İstemciler sayfasından alınan istemci kimliği.
client_secret İsteğe bağlı

Cloud Console İstemciler sayfasından alınan istemci gizli anahtarı.

code İlk istekten döndürülen yetkilendirme kodu.
code_verifier 1. adımda oluşturduğunuz kod doğrulayıcı.
grant_type OAuth 2.0 spesifikasyonunda tanımlandığı gibi, bu alanın değeri authorization_code olarak ayarlanmalıdır.
redirect_uri Belirli bir client_id için Cloud Console İstemciler sayfasında projeniz için listelenen yönlendirme URI'lerinden biri.

DPoP kullanımı isteğe bağlı olsa da daha fazla güvenlik için önerilir. DPoP'un güvenliği, özel anahtarın tek bir cihazla sınırlandırılmasına bağlıdır. Anahtarı, cihaz dışına kopyalanamayacak şekilde (ör. TPM'ler, Güvenli Alanlar veya diğer donanım destekli anahtar depoları kullanarak) saklamanızı öneririz. DPoP'u kullanmak için uygulamanızın, jeton uç noktasına yapılan her istek için yeni ve benzersiz bir DPoP kanıtı JWT'si oluşturması ve bunu HTTP istek başlığı olarak eklemesi gerekir.

Başlık Zorunlu Açıklama
DPoP İsteğe bağlı DPoP kanıtı, özel anahtarın sahipliğini kanıtlayan bir JWT'dir. Bu bir parametre değil, başlıktır. Sağlanırsa döndürülen jetonlar bu anahtara bağlanır. Her istek için yeni ve benzersiz bir kanıt oluşturulmalı ve istekle eşleşen htm (HTTP yöntemi) ve htu (HTTP URI) taleplerini içermelidir.

Aşağıdaki snippet'te örnek bir istek gösterilmektedir:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\
 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\
 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\
 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj\
 oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia\
 WF0IjoxNTYyMjYyNjE2fQ.2-GxA6T8lP4vfrg8v-FdWP0A0zdrj8igiMLvqRMUvwnQg\
 4PtFLbdLXiOSsX0x7NVY-FNyJK70nfbV37xRZT3Lg

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
redirect_uri=http://127.0.0.1:9004&
grant_type=authorization_code

DPoP kanıtı oluşturma

Aşağıdaki adımlarda, komut satırından OpenSSL kullanarak DPoP kanıtının nasıl oluşturulacağı gösterilmektedir:

  1. EC P-256 anahtar çifti oluşturma:
    openssl ecparam -name prime256v1 -genkey -noout -out dpop_private.pem
    openssl ec -in dpop_private.pem -pubout -out dpop_public.pem
  2. DPoP üstbilgisini oluşturun:

    Üstbilgi; typ, alg ve jwk (ortak anahtar) hak taleplerini içermelidir. x ve y değerleri, EC ortak anahtarınızın Base64Url kodlu koordinatlarıdır. Bu JSON'u Base64Url ile kodlayın:

    {
      "typ":"dpop+jwt",
      "alg":"ES256",
      "jwk": {
        "kty":"EC",
        "x":"YOUR_PUBLIC_KEY_X",
        "y":"YOUR_PUBLIC_KEY_Y",
        "crv":"P-256"
      }
    }
  3. DPoP yükünü oluşturun:

    Yükte jti (istek için benzersiz bir tanımlayıcı), htm (HTTP yöntemi, ör. POST), htu (HTTP URI, ör. https://oauth2.googleapis.com/token) ve iat (veriliş zamanı) bulunmalıdır. Önceki bir isteğe verilen yanıtta DPoP-Nonce üstbilgisinde sunucudan bir tek seferlik rastgele sayı aldıysanız bu tek seferlik rastgele sayı değerini bir nonce talebine eklemeniz gerekir. Tek seferlik rastgele sayı talebi, yetkilendirme kodu alışverişleri için isteğe bağlıdır ve yalnızca daha önce DPoP-Nonce üstbilgisi alındığında kullanılır. Bu JSON'u Base64Url ile kodlayın:

    {
      "jti":"JTI_VALUE",
      "htm":"POST",
      "htu":"https://oauth2.googleapis.com/token",
      "iat":YOUR_JWT_ISSUED_TIME,
      "nonce":"SERVER_PROVIDED_NONCE"
    }

    jti değeri, exchange türüne bağlıdır:

    • Yetkilendirme kodu değişimleri için jti, yetkilendirme kodunun Base64Url kodlamalı SHA256 karması olmalıdır: "jti":"BASE64URL(SHA256(AUTHORIZATION_CODE))".
    • Yenileme jetonu değişimleri için jti, istek başına benzersiz bir tanımlayıcı olmalıdır: "jti":"YOUR_UNIQUE_PER_REQUEST_IDENTIFIER".
  4. İspatı imzalama:

    Kodlanmış başlığı ve yükü bir nokta (.) ile birleştirin, ardından sonucu ES256 kullanarak özel anahtarınızla imzalayın. JWS'nin, imzanın ham R | S birleştirilmiş biçimde (P-256 için 64 bayt) olmasını gerektirdiğini unutmayın. Doğrudan OpenSSL kullanıyorsanız varsayılan ASN.1 DER kodlu imzayı bu ham biçime dönüştürmeniz gerekir.

Başarılı bir değişim, jetonları içeren bir 200 OK yanıtıyla belirtilir. Değişim sırasında geçerli bir DPoP kanıtı kullanılırsa Google'ın döndürdüğü yenileme jetonu, anahtarınıza DPoP ile bağlanır ancak erişim jetonları DPoP ile bağlanmaz. Erişim jetonları, DPoP yerine Bearer token_type değerini korur. Ayrıca Google, yanıtta bir DPoP-Nonce HTTP üst bilgisi döndürür. İstemciniz bu tek seferlik rastgele sayıyı önbelleğe almalı ve sonraki isteklerde (ör. yenileme jetonunu yeni bir erişim jetonuyla değiştirirken veya DPoP korumalı API'leri çağırırken) DPoP kanıtının nonce talebine dahil etmelidir. Bu erken verilen tek seferlik rastgele sayıyı kullanarak bir sonraki isteğinizde fazladan gidiş dönüş hatasını (use_dpop_nonce) önleyebilirsiniz.

DPoP'ye bağlı yenileme jetonlarıyla yapılan jeton değişimi istekleri için DPoP kanıtları eklenmelidir.

Başarısız değişim, DPoP başlığı beklendiği halde eksikse, geçersizse veya kanıt, jetona bağlı olandan farklı bir anahtar kullanıyorsa gerçekleşir. Bu durumlarda sunucu 400 Bad Request hatası döndürür. DPoP kanıtında eşleşmeyen htm veya htu talepleri, süresi dolmuş bir iat, yeniden kullanılan bir jti veya geçersiz bir imza varsa Google, invalid_dpop_proof hata kodunu döndürür. Yenileme jetonu değişimi sırasında olduğu gibi bir DPoP tek seferlik rastgele sayısı gerekiyorsa ve DPoP kanıtında nonce talebi eksikse veya tek seferlik rastgele sayı değeri sunucu tarafından kabul edilemiyorsa (ör. süresi dolmuş, zaten kullanılmış veya yanlışsa) Google, sonraki bir istekte kullanabileceğiniz yeni bir tek seferlik rastgele sayı içeren DPoP-Nonce HTTP üstbilgisiyle birlikte use_dpop_nonce hata kodu döndürür. Diğer hatalar invalid_grant döndürebilir.

Google, kısa süreli bir erişim jetonu ve yenileme jetonu içeren bir JSON nesnesi döndürerek bu isteğe yanıt verir.

Yanıtta aşağıdaki alanlar bulunur:

Alanlar
access_token Uygulamanızın bir Google API isteğini yetkilendirmek için gönderdiği jeton.
expires_in Erişim jetonunun saniye cinsinden kalan kullanım ömrü.
id_token Not: Bu özellik yalnızca isteğiniz openid, profile veya email gibi bir kimlik kapsamı içeriyorsa döndürülür. Değer, kullanıcıyla ilgili dijital olarak imzalanmış kimlik bilgilerini içeren bir JSON Web Token'dır (JWT).
refresh_token Yeni bir erişim jetonu almak için kullanabileceğiniz jeton. Yenileme jetonları, kullanıcı erişimi iptal edene veya yenileme jetonunun süresi dolana kadar geçerlidir. DPoP kullanıldıysa yenileme jetonu, DPoP kanıtını imzalamak için kullanılan özel anahtara bağlıdır. Yenileme jetonlarının, yüklü uygulamalar için her zaman döndürüldüğünü unutmayın.
refresh_token_expires_in Yenileme jetonunun saniye cinsinden kalan kullanım ömrü. Bu değer yalnızca kullanıcı zamana dayalı erişim izni verdiğinde ayarlanır.
scope access_token tarafından verilen erişim kapsamları, boşlukla ayrılmış, büyük/küçük harfe duyarlı dizelerden oluşan bir liste olarak ifade edilir.
token_type Döndürülen jetonun türü. DPoP kullanılsa bile bu değer her zaman Bearer olur.

Aşağıdaki snippet'te, DPoP kullanıldığında başarılı bir yanıt başlığı ve gövdesi örneği gösterilmektedir:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
DPoP-Nonce: AN3XwJjZsjnb0ZuWkRlek8QU7wY-Zhf-5IP6tO0tORz0KgtDT1Bo8FX-w4nz3r5lnepI

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

6. adım: Kullanıcıların hangi kapsamlara izin verdiğini kontrol edin

Birden fazla izin (kapsam) istediğinizde kullanıcılar uygulamanıza tüm izinlere erişim hakkı vermeyebilir. Uygulamanız, gerçekte hangi kapsamların verildiğini doğrulamalı ve bazı izinlerin reddedildiği durumları, genellikle reddedilen kapsamlara dayalı özellikleri devre dışı bırakarak sorunsuz bir şekilde ele almalıdır.

Ancak istisnalar bulunmaktadır. Alan genelinde yetki devri olan Google Workspace Enterprise uygulamaları veya Güvenilir olarak işaretlenen uygulamalar, ayrıntılı izinler için kullanıcı rızası ekranını atlar. Bu uygulamalarda kullanıcılar ayrıntılı kullanıcı rızası ekranını görmez. Bunun yerine, uygulamanız istenen tüm kapsamları alır veya hiçbirini almaz.

Daha ayrıntılı bilgi için Ayrıntılı izinleri işleme başlıklı makaleyi inceleyin.

Kullanıcının uygulamanıza belirli bir kapsam için erişim izni verip vermediğini kontrol etmek için erişim jetonu yanıtındaki scope alanını inceleyin. erişim jetonu tarafından verilen erişim kapsamları, boşlukla ayrılmış ve büyük/küçük harfe duyarlı dizelerden oluşan bir liste olarak ifade edilir.

Örneğin, aşağıdaki örnek erişim jetonu yanıtı, kullanıcının uygulamanıza salt okunur Drive etkinliği ve Takvim etkinlikleri izinlerine erişim izni verdiğini gösterir:

  {
    "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
    "expires_in": 3920,
    "token_type": "Bearer",
    "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
    "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
  }

Google API'lerini çağırma

Uygulamanız bir erişim jetonu aldıktan sonra, API'nin gerektirdiği erişim kapsamları verilmişse belirli bir kullanıcı hesabı adına Google API'sine çağrı yapmak için jetonu kullanabilirsiniz. Bunu yapmak için bir access_token sorgu parametresi veya bir Authorization HTTP üstbilgisi Bearer değeri ekleyerek erişim jetonunu API'ye gönderilen bir isteğe ekleyin. Mümkün olduğunda HTTP başlığı tercih edilir çünkü sorgu dizeleri sunucu günlüklerinde görünür. Çoğu durumda, Google API'lerine çağrılarınızı ayarlamak için bir istemci kitaplığı kullanabilirsiniz (örneğin, Drive Files API'yi çağırırken).

Tüm Google API'lerini deneyebilir ve kapsamlarını OAuth 2.0 Playground'da görüntüleyebilirsiniz.

HTTP GET örnekleri

Authorization: Bearer HTTP üst bilgisini kullanarak drive.files uç noktasına (Drive Files API) yapılan bir çağrı aşağıdaki gibi görünebilir. Kendi erişim jetonunuzu belirtmeniz gerektiğini unutmayın:

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

access_token sorgu dizesi parametresini kullanan kimliği doğrulanmış kullanıcı için aynı API'ye yapılan çağrı aşağıda verilmiştir:

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

curl örnek

Bu komutları curl komut satırı uygulamasıyla test edebilirsiniz. HTTP üstbilgisi seçeneğini (tercih edilen) kullanan bir örnek aşağıda verilmiştir:

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

Alternatif olarak sorgu dizesi parametresi seçeneğini de kullanabilirsiniz:

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

Erişim jetonunu yenileme

Erişim jetonlarının süresi belirli aralıklarla dolar ve ilgili API isteği için geçersiz kimlik bilgileri haline gelir. Jetonla ilişkili kapsamlara çevrimdışı erişim istediyseniz kullanıcıdan izin istemeden (kullanıcı mevcut olmadığında bile) erişim jetonunu yenileyebilirsiniz.

Uygulamanız, erişim jetonunu yenilemek için Google'ın yetkilendirme sunucusuna (https://oauth2.googleapis.com/token) istek gövdesinde aşağıdaki parametreleri içeren bir HTTPS POST isteği gönderir:

Ad Değer
client_id API Konsolu'ndan alınan istemci kimliği.
client_secret İsteğe bağlı

API Konsolu'ndan alınan istemci gizli anahtarı. (client_secret, Android, iOS veya Chrome uygulaması olarak kayıtlı istemcilerden gelen istekler için geçerli değildir.)

grant_type OAuth 2.0 spesifikasyonunda tanımlandığı gibi, bu alanın değeri refresh_token olarak ayarlanmalıdır.
refresh_token Yetkilendirme kodu değiş tokuşundan döndürülen yenileme jetonu.

DPoP kullanımı isteğe bağlı olsa da daha fazla güvenlik için önerilir. DPoP'u yenileme jetonuyla kullanmak için uygulamanızın, jeton uç noktasına yapılan her istek için yeni ve benzersiz bir DPoP kanıtı JWT'si oluşturması gerekir. Bu kanıt, ilk yetkilendirme kodu değişimi sırasında kullanılan özel anahtarla imzalanmalıdır. Uygulamanız, kanıtı HTTP istek başlığı olarak ekler.

Başlık Zorunlu Açıklama
DPoP İsteğe bağlı DPoP kanıtı, özel anahtarın sahipliğini kanıtlayan bir JWT'dir. Bu bir parametre değil, başlıktır. Sağlanırsa döndürülen jetonlar bu anahtara bağlanır. Her istek için yeni ve benzersiz bir kanıt oluşturulmalı ve istekle eşleşen htm (HTTP yöntemi) ve htu (HTTP URI) taleplerini içermelidir.

Aşağıdaki snippet'te örnek bir istek gösterilmektedir:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded
DPoP: DPOP_PROOF_JWT

client_id=your_client_id&
refresh_token=refresh_token&
grant_type=refresh_token

DPoP'u yenileme jetonuyla kullanmak için istek için yeni ve benzersiz bir DPoP kanıtı JWT'si oluşturmanız gerekir. Anahtar çiftini oluşturma ve JWT'yi oluşturma ile ilgili adım adım talimatlar için DPoP kanıtı oluşturma bölümüne bakın.

Başarılı bir değişim, yeni bir erişim jetonu içeren 200 OK yanıtıyla belirtilir. DPoP kullanıldığında token_type, Bearer olur. Başarılı bir yanıt, yenileme jetonu için DPoP kanıtının kabul edildiğini onaylar. Google, yanıtta yeni bir DPoP-Nonce HTTP başlığı da döndürebilir. Döndürülürse istemciniz bu tek seferlik rastgele sayıyı önbelleğe almalı ve sonraki isteklerde DPoP kanıtının nonce talebine dahil etmelidir.

DPoP başlığı eksik veya geçersizse ya da yanlış bir anahtar kullanıyorsa başarısız değişim gerçekleşir. Belirli DPoP hata kodları ve tek seferlik rastgele sayıların işlenmesiyle ilgili ayrıntılar için Başarısız değişim bölümüne bakın.

Aşağıdaki snippet'te, DPoP kullanıldığında başarılı bir yanıt başlığı ve gövdesi örneği gösterilmektedir:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
DPoP-Nonce: AN3XwJjZsjnb0ZuWkRlek8QU7wY-Zhf-5IP6tO0tORz0KgtDT1Bo8FX-w4nz3r5lnepI

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

Verilecek yenileme jetonlarının sayısıyla ilgili sınırlamalar olduğunu unutmayın. Bu sınırlamalardan biri istemci/kullanıcı kombinasyonu başına, diğeri ise tüm istemciler genelinde kullanıcı başınadır. Yenileme jetonlarını uzun süreli depolama alanına kaydetmeniz ve geçerli oldukları sürece kullanmaya devam etmeniz gerekir. Uygulamanız çok fazla yenileme jetonu isterse bu sınırlara takılabilir. Bu durumda eski yenileme jetonları çalışmayı durdurur.

Jeton iptali

Bazı durumlarda kullanıcılar bir uygulamaya verilen erişimi iptal etmek isteyebilir. Kullanıcı, Hesap Ayarları'nı ziyaret ederek erişimi iptal edebilir. Daha fazla bilgi için Hesabınıza erişimi olan üçüncü taraf siteleri ve uygulamaları destek dokümanındaki Site veya uygulama erişimini kaldırma bölümüne bakın.

Bir uygulamanın, kendisine verilen erişimi programatik olarak iptal etmesi de mümkündür. Programatik iptal; kullanıcının abonelikten çıktığı, bir uygulamayı kaldırdığı veya bir uygulama için gereken API kaynaklarının önemli ölçüde değiştiği durumlarda önemlidir. Başka bir deyişle, kaldırma işleminin bir parçası olarak, uygulamaya daha önce verilen izinlerin kaldırıldığından emin olmak için bir API isteği gönderilebilir.

Bir jetonu programatik olarak iptal etmek için uygulamanız https://oauth2.googleapis.com/revoke adresine istek gönderir ve jetonu parametre olarak ekler:

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
        https://oauth2.googleapis.com/revoke?token={token}

Jeton, erişim jetonu veya yenileme jetonu olabilir. Jeton bir erişim jetonuysa ve karşılık gelen bir yenileme jetonu varsa yenileme jetonu da iptal edilir.

İptal işlemi başarıyla işlenirse yanıtın HTTP durum kodu 200 olur. Hata koşulları için hata koduyla birlikte bir HTTP durum kodu 400 döndürülür.

Uygulama yönlendirme yöntemleri

Özel URI şeması

Özel URI şemaları, uygulamanızı açmak için özel olarak tanımlanmış bir şema kullanan bir derin bağlantı biçimidir.

Chrome uygulamalarında özel URI şemaları kullanmaya alternatif

OAuth 2.0 yanıtını doğrudan uygulamanıza gönderen ve yönlendirme URI'si ihtiyacını ortadan kaldıran Chrome Identity API'yi kullanın.

Geri döngü IP adresi (macOS, Linux, Windows masaüstü)

Bu URL'yi kullanarak yetkilendirme kodunu almak için uygulamanızın yerel web sunucusunu dinlemesi gerekir. Bu, tüm platformlarda olmasa da çoğunda mümkündür. Ancak platformunuz destekliyorsa yetkilendirme kodunu almak için önerilen mekanizma budur.

Uygulamanız yetkilendirme yanıtını aldığında, en iyi kullanılabilirlik için kullanıcıya tarayıcıyı kapatıp uygulamanıza dönmesini söyleyen bir HTML sayfası göstererek yanıt vermelidir.

Önerilen kullanım macOS, Linux ve Windows masaüstü uygulamaları
Form değerleri Uygulama türünü Masaüstü uygulaması olarak ayarlayın.

Manuel kopyalama/yapıştırma (Desteği sonlandırıldı)

Uygulamalarınızı koruma

Chrome için uygulama sahipliğini doğrulama

Uygulama kimliğine bürünme riskini azaltmak için uygulamanızın sahipliğini doğrulayabilirsiniz.

Doğrulama sürecini tamamlamak için Chrome Web Mağazası geliştirici hesabınızı kullanmanız gerekir. Doğrulamanın başarılı olması için aşağıdaki koşulların karşılanması gerekir:

  • Chrome Web Mağazası Geliştirici Kontrol Paneli'nde, doğrulama işlemini tamamladığınız Chrome uzantısı OAuth istemcisiyle aynı öğe kimliğine sahip kayıtlı bir öğeniz olmalıdır.
  • Chrome Web Mağazası öğesinin yayıncısı olmanız gerekir. Chrome Web Mağazası Geliştirici Kontrol Paneli'nde erişim yönetimi hakkında daha fazla bilgi edinin.

Chrome uzantısı istemcisinin Uygulama Sahipliğini Doğrulama bölümünde, doğrulama sürecini tamamlamak için Sahipliği Doğrula düğmesini tıklayın.

Not: Hesabınıza erişim izni verdikten sonra doğrulama sürecini tamamlamadan önce birkaç dakika bekleyin.

Doğrulama başarılı olursa doğrulama sürecinin başarılı olduğunu onaylayan bir bildirim gösterilir. Aksi takdirde bir hata istemi gösterilir.

Başarısız bir doğrulamayı düzeltmek için aşağıdakileri deneyin:

  • Chrome Web Mağazası Geliştirici Kontrol Paneli'nde, doğrulama işlemini tamamladığınız Chrome uzantısı OAuth istemcisiyle aynı öğe kimliğine sahip kayıtlı bir öğe olduğundan emin olun.
  • Uygulamanın yayıncısı olduğunuzdan emin olun. Yani uygulamanın bireysel yayıncısı veya uygulamanın grup yayıncısının bir üyesi olmanız gerekir. Chrome Web Mağazası Geliştirici Kontrol Paneli'nde erişim yönetimi hakkında daha fazla bilgi edinin.
  • Grup yayıncı listenizi yeni güncellediyseniz grup yayıncı üyelik listesinin Chrome Web Mağazası Geliştirici Kontrol Paneli'nde senkronize edildiğini doğrulayın. Yayıncı üyelik listenizi senkronize etme hakkında daha fazla bilgi edinin.

Zamana dayalı erişim

Zamana dayalı erişim, kullanıcıların bir işlemi tamamlamak için uygulamanıza sınırlı bir süre boyunca verilerine erişim izni vermesine olanak tanır. Zaman tabanlı erişim, izin akışı sırasında belirli Google ürünlerinde kullanılabilir. Bu sayede kullanıcılar sınırlı bir süre için erişim izni verebilir. Verilerin tek seferlik aktarımını sağlayan Data Portability API buna örnek olarak verilebilir.

Kullanıcı, uygulamanıza zamana dayalı erişim izni verdiğinde yenileme jetonunun süresi belirtilen sürenin sonunda dolar. Yenileme jetonlarının belirli durumlarda daha erken geçersiz kılınabileceğini unutmayın. Ayrıntılar için bu durumlara bakın. Yetkilendirme kodu değişimi yanıtında döndürülen refresh_token_expires_in alanı, bu gibi durumlarda yenileme jetonunun süresi dolana kadar kalan süreyi gösterir.

Daha fazla bilgi

IETF'nin Yerel Uygulamalar için OAuth 2.0 adlı mevcut en iyi uygulaması, burada açıklanan en iyi uygulamaların çoğunu oluşturur.

Hesaplar Arası Koruma'yı uygulama

Kullanıcılarınızın hesaplarını korumak için atmanız gereken ek bir adım, Google'ın Hesaplar Arası Koruma Hizmeti'nden yararlanarak Hesaplar Arası Koruma'yı uygulamaktır. Bu hizmet, kullanıcı hesabındaki önemli değişiklikler hakkında uygulamanıza bilgi veren güvenlik etkinliği bildirimlerine abone olmanızı sağlar. Ardından, etkinliklere nasıl yanıt vereceğinize karar vermek için bu bilgileri kullanarak harekete geçin.

Google'ın Hesaplar Arası Koruma hizmeti tarafından uygulamanıza gönderilen etkinlik türlerine örnek olarak şunlar verilebilir:

  • https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
  • https://schemas.openid.net/secevent/oauth/event-type/token-revoked
  • https://schemas.openid.net/secevent/risc/event-type/account-disabled

Hesaplar Arası Koruma'yı nasıl uygulayacağınız hakkında daha fazla bilgi ve mevcut etkinliklerin tam listesi için Kullanıcı hesaplarını Hesaplar Arası Koruma ile koruma sayfasını inceleyin.