LinkedIn
Instagram
WhatsApp
Telgraf
Google Takvim
Slack Topluluğuna KatılınGmail API Anahtarı vs OAuthOAuth'u Neden Atlayamazsınız
Google API anahtarı ile Gmail'e erişebilir misiniz? Kısa cevap: hayır. Gmail API'si özel kullanıcı verilerine eriştiği için her istekte OAuth 2.0 aracılığıyla kullanıcının açık rızası gereklidir. Bu kılavuz, API anahtarını denerseniz göreceğiniz hatayı, bugün mevcut olan 3 gerçek kimlik doğrulama yolunu ve 3 satır kodla bir Gmail posta kutusuna nasıl bağlanacağınızı ele almaktadır birleşik e-posta API'si.
// Gmail API Anahtarı mı OAuth mu - karar
// ----------------------------------------
// YANLIŞ: API anahtarı Gmail ile ÇALIŞMIYOR
const Res = bekliyor fetch(
`https://gmail.googleapis.com/gmail/v1/
users/me/messages?anahtar=SENIN_API_ANAHTARIN`
);
// Döndürür: 401 Giriş Gerekli
OAuth 2.0 erişim belirteci
const Res = bekliyor fetch(
'https://gmail.googleapis.com/gmail/v1/users/me/messages',
{ headers: {
'Authorization': Taşıyıcı ${erişimJetonu}`
} }
);
// VEYA OAuth'u tamamen atlayın - Unipile kullanın
const e-postalar = bekliyor unipile.e-posta.list(
{ hesapId: 'bağlı-hesap-kimliği' }
);
Gmail API ile API Anahtarı Kullanabilir Misiniz?
Daha önce Google Cloud üzerinde bir şeyler geliştirdiyseniz, Haritalar veya Çeviri için API anahtarlarının gayet iyi çalıştığını bilirsiniz. Bu nedenle Gmail ile de aynı yaklaşımı denemek doğal olacaktır. Ancak işler yolunda gitmeyecek. Tam olarak neler olacağını ve nedenini açıklıyoruz - ayrıca derinlemesine dalmadan önce iki cümlelik özetini de veriyoruz.
Hayır. Google API anahtarları Gmail API'sine karşı kimlik doğrulayamaz. Gmail, açık kullanıcı rızası gerektiren özel kullanıcı verilerine OAuth 2.0 aracılığıyla erişir. Gmail uç noktalarından herhangi birinde bir API anahtarını OAuth erişim jetonuyla değiştirmeyi sağlayan hiçbir bayrak, hiçbir başlık, hiçbir çözüm yoktur. Gmail API'si şöyle bir yanıt dönecektir: 401 Giriş Gerekli veya Kimlik doğrulanmamış kullanım için günlük 403 limit aşıldı Her seferinde hata.
API Anahtarı - Yalnızca herkese açık veriler için geçerlidir
Bir API anahtarı, faturalandırma ve kota için Google Cloud projenizi tanımlar. Kullanıcı hesaplarına dokunmayan genel API'lerle (Haritalar, Çeviri, YouTube genel verileri) çalışır. Gmail asla genel veri değildir.
OAuth 2.0 - Gmail API İçin Gereklidir
OAuth 2.0, kullanıcı açıkça onay verdikten sonra kullanıcıya özel bir erişim belirteci üretir. Gmail API, hem kullanıcının kimliğini hem de onaylanan erişimin kapsamını doğrulamak için her istekte bu belirteci okur. Geçerli bir erişim belirteci yoksa yanıt da olmaz.
Bir API Anahtarının Google Cloud'da Gerçekten Ne İşe Yaradığı (ve Yaramadığı)
API anahtarları ve OAuth jetonları, iki farklı sorunu çözen iki ayrı mekanizmadır. Google API'lerine başlarken bunları karıştırmak en yaygın hatalardan biridir. İşte net ayrım.
Google Haritalar Platformu - Coğrafi Kodlama, Yönler, Yerler (kullanıcı hesabı gerekmez)
Bulut Çeviri API - Metin çevirme, dil algılama
YouTube Veri API'si - Genel video meta verilerini, kanalları, oynatma listelerini okuma
Bulut Görseli / Doğal Dil - Yüklediğiniz içeriği işleyen yapay zeka API'leri
Faturalama + Kota takibi - Tüm API anahtar kullanımları projenize göre ölçülür
Gmail API - Bir kullanıcının posta kutusunu okuma, gönderme veya yönetme
Google Takvim API'si - Kullanıcının takvim etkinliklerini okuma veya yazma
Google Drive API - Bir kullanıcının dosyalarına erişme, yükleme veya listeleme
Google Workspace Yönetici SDK'sı - Bir alan üzerindeki yönetici kapsamlı herhangi bir işlem
İnsanlar API (kullanıcı verileri) Kullanıcının kişi bilgilerine veya profiline erişen herhangi bir uç nokta
Kural basit: Bir API, kullanıcının hesap verilerine erişiyorsa, Google kullanıcının OAuth 2.0 aracılığıyla kimliğini doğrulaması gerektirir. API anahtarları kullanıcı kimlik bilgileri değil, proje kimlik bilgileridir. Gmail API her zaman kullanıcı verilerine erişir. İstisnası yoktur. Bu kural, uygulamanızın herkese açık veya şirket içi olmasına bakılmaksızın geçerlidir.
Gmail Neden OAuth 2.0 Gerektiriyor
OAuth 2.0, yavaşlatmak için Google'ın icat ettiği bürokratik bir engel değildir. Özel kullanıcı verilerine kapsamlı, geri alınabilir, denetlenebilir erişim sağlamanın tek teknik olarak sağlam yoludur. Gmail'in üç temel gereksinimi, bir API anahtarının neden asla yerine geçemeyeceğini açıklamaktadır.
Kullanıcı rızası pazarlık konusu değildir
Gmail verileri, uygulamanıza değil, kullanıcıya aittir. OAuth 2.0, kullanıcının açıkça "evet, bu uygulama gelen kutumu okuyabilir" dediği mekanizmadır. Onay akışı yoksa erişim de yoktur. Bu, sadece teknik bir kısıtlama değil, GDPR ve Google platform politikaları kapsamında yasal bir gerekliliktir.
Kapsamlı, geri alınabilir erişim
OAuth jetonları, uygulamanın neler yapabileceğini ve yapamayacağını (yalnızca okuma, gönderme, tam erişim) kesin olarak belirten kapsamlar içerir. Kullanıcılar, tam olarak hangi erişimi verdiklerini görebilir ve Google Hesapları ayarlarından istedikleri zaman bu erişimi iptal edebilirler. Bir API anahtarı hiçbir şey sağlamaz ve kullanıcı düzeyinde hiçbir şeyi iptal edemez.
Token süresi dolumu kullanıcıları korur
Gmail API erişim belirteçleri süresi dolar (genellikle 1 saat). Bu, çalınan bir belirtecin kısa bir süre sonra işe yaramaz hale geleceği anlamına gelir. Uygulamanız, belirteki iptal edilebilen bir yenileme belirteci kullanarak sessizce yenilemelidir. API anahtarları ise, kullanıcı düzeyinde iptal mekanizması olmayan, uzun ömürlü proje kimlik bilgileridir.
Google, Gmail için kullanıcı adı/şifre kimlik doğrulamasını ("Temel Kimlik Doğrulama") kullanımdan kaldırdı Eylül 2024. Depolanan kimlik bilgilerini doğrudan kullanan eski entegrasyonlarınız varsa artık çalışmamaktadır. Gmail API için hem yeni hem de geçirilen entegrasyonlarda kalan tek kimlik doğrulama mekanizması OAuth 2.0'dir. Google'un resmi duyurusunu gör.
SaaS'ınızda birden fazla Gmail hesabı için OAuth işlemleri yapmanız mı gerekiyor? Unipile, her bağlı hesap için onay ekranını, jeton değişimini ve sessiz yenilemeyi yönetir - böylece kodunuz asla bir jetonla temas etmez.
Unipile ile oluşturunGmail API için 3 Gerçek Kimlik Doğrulama Yolu
OAuth'un kaçınılmaz olduğunu kabul ettiğinizde, soru şu hale gelir: Kullanım durumunuza hangi OAuth yolu uyuyor? Mimari olarak farklı üç seçenek vardır - her biri karmaşıklık, kullanıcı kapsamı ve bakım yükü açısından farklı ödünleşimlere sahiptir.
| Kriter | OAuth 2.0 İstemci Kimliği (3 aşamalı) | Servis Hesabı + DWD | Birleşik API (Unipile) |
|---|---|---|---|
| Kullanıcı onayı gerekli mi? | |||
| Kişisel Gmail ile çalışır mı? | |||
| Çok kiracılı SaaS | |||
| D token yönetimi | Kodunuz, jetonları depolar ve yeniler. Bakım gerektiren |
Hizmet hesabı JSON anahtarı Yönetici tarafından yönetilen |
Unipile tüm belirteçleri işler Sıfır bakım |
| Google onay ekranı incelemesi? | |||
| Ayrıca Outlook + IMAP destekliyor mu? | |||
| İlk e-posta okuma süresi | 2-4 saat kurulum OAuth uygulaması + kapsamlar + onay ekranı |
1-2 saat kurulum Çalışma alanı yöneticisi gerekli |
15 dakikanın altında API anahtarı + bağlı hesap |
| En iyisi | Harici kullanıcıların Gmail'ine bağlanan SaaS uygulamaları | Kuruluşunuz İçin Kurumsal Çalışma Alanı Araçları | Herhangi bir e-posta API kullanım durumu - OAuth işlemleri yok |
Yol 1 - OAuth 2.0 İstemci Kimliği (Çok Kiracılı SaaS)
Kendi Gmail hesaplarını bağlayan müşterilerinizle bir SaaS ürünü oluşturuyorsanız, OAuth 2.0 yetkilendirme kodu akışı standart yoldur. Bu, 3 bacaklı akıştır: uygulamanız, Google ve son kullanıcı. Hassas kapsamlar için bir Google Cloud projesi ayarlamayı ve onay ekranı doğrulama sürecinden geçmeyi gerektirir. Derinlemesine incelemek için E-posta API'leri için OAuth akışı ayrıntılı olarak, özel kılavuzumuza bakın.
Google Cloud Console'da OAuth 2.0 kimlik bilgileri oluşturun
API'ler ve Hizmetler > Kimlik Bilgileri > Kimlik Bilgileri Oluştur > OAuth istemci kimliği'ne gidin. "Web uygulaması"nı seçin. Uygulamanız için yetkili yönlendirme URI'lerini yapılandırın. Bu, sizin için şunu oluşturacaktır client_id ve client_secret.
Gmail API'yi etkinleştirin ve kapsamlarınızı bildirin
APIs ve Hizmetleri > OAuth rozet ekranı'na gidin. İhtiyacınız olan Gmail kapsamlarını ekleyin (örneğin. gmail.yalnızcaoku, gmail.gönderHassas ve kısıtlı kapsamlar Google doğrulaması gerektirir; bu süreç günler hatta haftalar sürebilir.
Kullanıcıları Google'ın yetkilendirme URL'sine yönlendirin
Kullanıcı uygulamanızda "Gmail Bağlan" düğmesine tıkladığında, sizi Google'a yönlendirecektir. client_id, kapsamlar ve yönlendirme_url'si. Onay verdikten sonra Google, yönlendirme URI'nize bir yetkilendirme kodu gönderir.
Kodları jetonlarla değiştirin ve yenileme jetonunu saklayın
Yetkilendirme kodunu Google'ın belirteç uç noktasına POST edin. Bir şey alacaksınız erişim_belirteci (yaklaşık 1 saat sonra sona erer) ve bir yenileme_belirteci (uzun ömürlü). Yenileme belirtecini güvenli bir şekilde saklayın; bu, kullanıcıya yeniden sormadan yeni erişim belirteçleri almanızı sağlar.
const { google } = require('googleapis');
const oauth2İstemci = yeni google.yetki.OAuth2(
process.env.GMAIL_CLIENT_ID,
process.env.GMAIL_CLIENT_SECRET,
process.env.GMAIL_YENIDENYONLENDIRME_URI
);
// Adım 1: Yetkilendirme URL'sini oluştur
const authUrl = oauth2Müvekkil.generateAuthUrl({
erişim_türü: 'çevrimdışı', // yenileme jetonu al
kapsam: [
'https://www.googleapis.com/auth/gmail.readonly',
'https://www.googleapis.com/auth/gmail.send'
]
});
// Adım 2: Kodları jetonlarla değiştirin (geri çağırma işleyicinizde)
async function Geri Çağrı Yap(kod) {
const { jetonlar } = bekliyor oauth2Müvekkil.token al(kod);
oauth2Müvekkil.kimlik bilgilerini ayarla(belirteçler);
// Tokenları.refresh_token'ı veritabanında güvenli bir şekilde saklayın
return jetonlar;
}
// Adım 3: Erişim jetonunu Gmail API'sini çağırmak için kullanın
async function mesajları listele(accessToken) {
const gmail = google.gmail({ sürüm: 'v1', yetkilendirme: oauth2Client });
const Res = bekliyor gmail.users.messages.list{userId: 'ben' });
return res.data.mesajlar;
}Yenileme jetonlarını büyük ölçekte yönetmek, #1'in en büyük zorluğu kendi yönettiğiniz Gmail OAuth'unda. Token rotasyonu, veritabanı geçişleri, süresi dolmuş tokenlar için sessiz hatalar - bunların hepsi, kullandığınızda otomatik olarak halledilir birleşik e-posta API sağlayıcısı.
Gmail entegrasyonunuzu oluşturunYol 2 - Hizmet Hesabı + Etki Alanı Geniş Kapsamlı Yetkilendirme (Workspace Dahili)
Kullanım senaryonuz bir Google Workspace kuruluşuna dahili ise - dahili araçlar, İK otomasyonu veya şirket genelinde bir e-posta analiz panosu düşünün - Alan genelinde Yetkilendirme'ye (DWD) sahip hizmet hesapları, kullanıcı başına onay akışları olmadan posta kutularına erişmenizi sağlar. Bir Workspace yöneticisi yetkilendirmeyi bir kez verir. Kritik uyarı: Bu yol kişisel Gmail adresleri için çalışmaz.
Hizmet hesapları kişisel Gmail hesaplarına (@gmail.com) erişemez. DWD yalnızca bir Google Workspace alanında çalışır. Kullanıcılarınız kişisel Gmail adresleriyle kaydolursa, Yol 1'i (OAuth İstemci Kimliği) veya Yol 3'ü (Birleşik API) kullanmalısınız. Kişisel bir hesapta DWD denemesi 403 hatası verir.
Çalışma alanı yöneticisi gerekli: DWD'nin, admin.google.com adresinden bir Google Workspace yöneticisi tarafından yapılandırılması gerekir. Yönetici erişiminiz olmadan bir geliştirici olarak bunu yapamazsınız.
JSON anahtar güvenliği: Servis hesabı JSON anahtarı uzun ömürlü bir kimlik bilgisi. Özel bir anahtar gibi davranın - düzenli olarak döndürün ve asla kaynak denetimine COMMIT yapmayın.
Kapsam bildirimi gerekli: Yönetici, DWD kurulumu sırasında her Gmail kapsamını açıkça onaylamalıdır. Kapsamları çalışma zamanında talep edemezsiniz. Bkz. Google'ın DWD kılavuzu.
itibaren google.oauth2 İthalat servis_hesabı
itibaren googleapiclient.discovery İthalat inşa etmek
# Hizmet hesabınızın JSON anahtarına giden yol
HİZMET_HESABI_DOSYASI = 'service-account.json'
KOŞULLAR = [
'https://www.googleapis.com/auth/gmail.readonly'
]
# Çalışma Alanı etki alanınızda bir kullanıcı kimliğine bürünme
# (Etki Alanı Çapında Yetki Devri, yönetici tarafından etkinleştirilmelidir)
fonksiyon gmail_servisi_al(kullanici_eposta):
kimlik bilgileri = service_account.Credentials.servis_hesabından_dosya(
HİZMET_HESABI_DOSYASI,
kapsamlar=KOŞULLAR
)
# Bu, etki alanı genelinde yetki devri: kullanıcı kimliğine bürünme
devredilmiş_kimlik bilgileri = kimlik bilgileri.konu_ile(kullanıcı_e-postası)
return inşa etmek('gmail', 'v1', kimlik bilgileri=devredilen_kimlikler)
# Bir Çalışma Alanı kullanıcısının mesajlarını listele
hizmet = gmail_servisi_al('alice@yourcompany.com')
Sonuçlar = service.users().messages().list(
kullanıcıId='ben'
).yürüt()Yol 3 - Birleştirilmiş E-posta API'si (OAuth Artık Kodundan Kaçının)
Eğer bir üretim SaaS uygulamasında e-posta okumak, göndermek veya senkronize etmek istiyorsanız ve OAuth altyapısını yönetmek için mühendislik kaynakları harcamak istemiyorsanız, Unipile gibi birleşik bir e-posta API'si tüm kimlik doğrulama katmanını soyutlar. Anlayın E-posta senkronizasyonu arka planda nasıl çalışır, veya doğrudan koda gidin. Bu yaklaşım ayrıca size tek bir API altında Gmail, Outlook ve IMAP'ı sunar - her sağlayıcı için ayrı entegrasyona gerek kalmaz.
Google Cloud kurulumu gerekmez
Google'dan yetkilendirme ekranı, kapsam incelemesi yok. Unipile'ın doğrulanmış OAuth uygulaması kullanıcı yetkilendirmesini halleder.
Otomatik jeton döndürme
Erişim belirteçleri ve yenileme belirteçleri tamamen Unipile tarafından yönetilir. Veritabanınız hiçbir Google OAuth belirteci saklamaz.
Gmail + Outlook + IMAP ile çalışır
Tek bir API, üç sağlayıcı evreni. Siz E-posta senkronizasyon API sağlayıcılarını karşılaştırın, sağlayıcılar arası destek önemli bir farklılaştırıcıdır.
Yeni iletilerde webhook teslimatı
Unipile, bağlı her hesap için Gmail API'sini yoklamak yerine, yeni e-posta olaylarını gerçek zamanlı olarak webhook uç noktanıza iletir.
// Unipile üzerinden bir Gmail posta kutusunu okumak için 3 satır
OAuth kurulumu yok, token yönetimi yok
const { UnipileClient } = require('unipile-node-sdk');
const müşteri = yeni UnipileClient({
token: process.env.UNIPILE_API_KEY
});
// Bağlı bir Gmail hesabındaki e-postaları listele
// accountId = Unipile bağlantılı hesap kimliği
const e-postalar = bekliyor client.email.mesajları listele({
account_id: 'bağlı-hesap-kimliği',
Limit: 20
});
// Bağlı hesap adına e-posta gönder
bekliyor client.email.gönder({
account_id: 'bağlı-hesap-kimliği',
to: 'recipient@example.com',
Konu: 'Unipile'dan merhaba',
body: 'Görünürde OAuth belirteci yok.'
});
// Outlook ve IMAP için aynı şekilde çalışır
// Sadece hesap_kimliğini değiştirOAuth operasyonları olmadan Gmail entegrasyonunuzu oluşturun
Başlat Gmail API entegrasyonu için eksiksiz kılavuz, ardından kimlik doğrulama ve senkronizasyon katmanı olarak Unipile ile dağıtın.
Gmail'de API Anahtarı Kullanmaya Çalışırken Yapılan Yaygın Hatalar
Gmail API çağrınız başarısız olduğu için bu makaleye ulaştıysanız, burada karşılaşacağınız iki hata ve her birinin tam olarak ne anlama geldiği yer almaktadır - ham yanıt gövdesi ile birlikte bunları anında tanıyabilmeniz için.
Bir API anahtarıyla Gmail API'sine bir istek gönderdiniz?anahtar=AIza...) veya hiç yetkilendirme olmadan. Gmail API, geçerli bir OAuth 2.0 erişim belirteci gerektirir Yetkilendirme: Bearer başlık. Bu göreceğiniz ilk hatadır API anahtarını ilk kez denerken.
Düzelt: Yukarıdaki 3 kimlik doğrulama yolundan birini uygulayın. API anahtarı çözüm değil - bir OAuth erişim belirtecine ihtiyacınız var.
HTTP/1.1 401 Yetkilendirilmemiş
İçerik-Türü: uygulama/json
{
"hata": {
"kod": 401,
"mesaj": "İstek, gerekli kimlik doğrulama kimlik bilgilerini eksik. OAuth 2 erişim jetonu, oturum çerezi veya geçerli başka bir kimlik doğrulama kimlik bilgisi bekleniyor. Bkz. https://developers.google.com/identity/sign-in/web/...",
"durum": "DOĞRULANAMADI",
"hatalar": [{
"mesaj": "Oturum Gerekli",
"alan": "googleapis.com",
"neden": "gerekli",
"konum": "Authorization",
"konumTipi": "header"
}]
}
}Tekrarlanan kimliği doğrulanmamış isteklerden sonra (API anahtarı ile bile), Google'ın kota sistemi IP'nizden veya projenizden gelen kimliği doğrulanmamış daha fazla çağrıyı engeller. Bu, kimliği doğrulanmış kullanıcılar için bir hız sınırı değildir - özellikle şunu ifade eder İstekleriniz hiçbir zaman onaylanmadı. ve anonim çağrılar için küçük ücretsiz kota hakkınızı doldurdunuz.
Düzelt: Yukarıdakiyle aynı - API anahtar yaklaşımınız asla işe yaramaz. OAuth 2.0 erişim belirteçlerini kullanın. İstekleriniz geçerli bir Bearer jetonu taşıdığında bu hata kaybolacaktır.
HTTP/1.1 403 Yasaklanmış
İçerik-Türü: uygulama/json
{
"hata": {
"kod": 403,
"mesaj": "Kimliği Doğrulanmamış Kullanım İçin Günlük Limit Aşıldı.
Devam eden kullanım için
kayıt gereklidir.",
"durum": "KAYNAK_TÜKENDİ",
"hatalar": [{
"mesaj": "Kimliği Doğrulanmamış Kullanım İçin Günlük Limit Aşıldı.",
"alan": "kullanımSınırları",
"neden":
"gunlukLimitAsildiKayitsiz"
}]
}
}Gerçekten İhtiyacınız Olacak Gmail API Kapsamları
OAuth'un gerekli olduğunu kabul ettikten sonra, kapsam seçimi bir sonraki kritik karardır. Google, Gmail kapsamlarını ortaya çıkardıkları verinin hassasiyetine göre üç kategoriye ayırır. İhtiyacınızdan fazlasını istemek daha uzun bir doğrulama sürecini tetikler ve bazı durumlarda Google tarafından tam bir güvenlik değerlendirmesini gerektirir.
Hassas kapsamlar (sarı) Google'dan OAuth onay ekranınızı incelemesini ve uygulamanızın gizlilik politikasını doğrulamasını isteyin. Kısıtlı kapsamlar (kırmızı) resmi bir güvenlik değerlendirmesi, bir video gösterimi ve bazen de üçüncü taraf bir güvenlik denetimi gerektirir. Kısıtlı kapsam onayı için minimum 2-6 hafta planlayın. Kimlik doğrulama katmanınız olarak Unipile kullanırsanız, bu doğrulama süreci uygulamanız değil, Unipile'a aittir.
| Kapsam | Erişim Seviyesi | Katman | Kullanım Örneği |
|---|---|---|---|
| gmail.yalnızcaoku | Tüm mesajları, iş parçacıklarını, etiketleri, ayarları oku | Hassas | E-posta analitiği, gelen kutusu denetim araçları, CRM senkronizasyonu (sadece okuma) |
| gmail.gönder | Kullanıcı adına e-posta gönder | Hassas | İşlemsel kullanıcı tarafı e-postaları, CRM takip e-postaları, erişim araçları |
| gmail.olustur | Taslakları oluştur, oku, güncelle, sil; mesaj gönder | Hassas | E-posta oluşturucu entegrasyonları, taslak yönetimi |
| gmail.değiştir | Oku, gönder, değiştir (etiketler, arşivle) - silme yok | Kısıtlı | Tam gelen kutusu yönetimi, yazma ile CRM senkronizasyonu, arşivleme iş akışları |
| mail.google.com | Tam erişim - oku, yaz, sil, ayarlar | Kısıtlı | Tam özellikli e-posta istemcileri, yedekleme araçları, yönetici geçişi |
| gmail.metaveri | Yalnızca mesaj meta verileri (gövde yok) | Hassas değil | E-posta hacmi, gönderici/alıcı kalıpları (içerik olmadan) üzerinde analiz |
Gmail.modify veya mail.google.com'a ihtiyaç duyan çok kiracılı bir SaaS oluşturmak mı? Kısıtlı kapsam incelemesi, lansman zaman çizelgenize haftalar ekler. Unipile ile onay ekranı incelemesini tamamen atlar, Unipile'ın doğrulanmış OAuth uygulaması entegrasyonunuzun ihtiyaç duyduğu kapsamları kapsar.
Unipile ile inşa edinKarar Ağacı: Kullanım Durumunuz İçin Hangi Kimlik Doğrulama Yöntemi?
Sorulara vereceğiniz üç yanıtla projeniz için hangi Gmail API kimlik doğrulama yolunun geçerli olduğunu tam olarak öğreneceksiniz. Evrensel bir cevap yok - her yol farklı bir sorunu çözüyor. Tam bilgi için Gmail API entegrasyonu için eksiksiz kılavuz, Gmail hub'ına devam edin. Outlook / Microsoft 365 karşılığı, Microsoft Graph OAuth kılavuzumuza bakın.
Müşterilerin kendi Gmail hesaplarını bağladığı bir SaaS uygulaması
Kullanıcılarınız harici mi (çalışanlarınız değil mi)?
Evet - bunlar kişisel Gmail veya Google Workspace hesaplarına sahip müşterilerinizdir.
Birçok farklı Google alanını desteklemeniz gerekiyor mu?
Evet - çoklu kiracı. Her kullanıcı kendi hesabını bağlar.
Veya OAuth altyapısını tamamen atlamak için Yol 3 (Birleşik API).
Kendi Google Workspace kuruluşunuz için dahili araç
Tüm kullanıcılar aynı Workspace alan adında mı (çalışanlarınız mı)?
Evet - yalnızca company.com hesapları. Harici Gmail kullanıcıları kabul edilmez.
DWD'yi yapılandırabilen bir Workspace yöneticiniz var mı?
Evet - yönetici erişimi admin.google.com adresinde mevcuttur.
Kullanıcı başına onay akışı yok. Yönetici bir kez yetki verir.
Tek bir API altında Gmail + Outlook + IMAP ihtiyacı olan SaaS uygulaması
Kullanıcılarınızın Gmail, Outlook ve IMAP hesapları karışık mı?
Evet - her kullanıcının hangi sağlayıcıya bağlanacağını tahmin edemezsiniz.
Sağlayıcı başına ayrı OAuth entegrasyonlarını çalıştırmaktan kaçınmak ister misiniz?
Evet - Google OAuth + Microsoft OAuth + IMAP yönetimi çok fazla karmaşıklık.
Tek bir API anahtarı. Gmail, Outlook, IMAP. OAuth işlemleri yok.
Gmail entegrasyonunuzu bugün oluşturmaya başlayın
Hangi yolu seçerseniz seçin, Unipile size bir Birleşik e-posta API genel bakışı Bir yaklaşıma bağlı kalmadan önce mimariyi anlamak için. Veya doğrudan kontrol paneline gidin ve ilk hesabınızı dakikalar içinde bağlayın.
Sıkça Sorulan Sorular
Gmail API kimlik doğrulaması, API anahtarları ile OAuth belirteçleri arasındaki farklar ve OAuth'ı kendiniz yönetmeden Gmail'e programlı olarak erişme hakkında en sık sorulan sorular.
Gmail'e erişmek için bir Google API anahtarı kullanabilir miyim?
Hayır. Google API tuşları yalnızca Haritalar, Çeviri veya YouTube Verileri (herkese açık içerik) gibi herkese açık, kullanıcıya özgü olmayan API'ler için çalışır. Gmail API erişimleri özel kullanıcı posta kutusu verileri, OAuth 2.0 aracılığıyla açık kullanıcı onayı gerektiren. API anahtarıyla Gmail API'sine bir istek göndermek bir hata döndürür 401 Giriş Gerekli veya Kimlik doğrulanmamış kullanım için günlük 403 limit aşıldı hata - her zaman, istisnasız.
Gmail API OAuth 2.0 gerektirir mi?
Evet, her zaman. Gmail API erişimi kullanıcı verilerine erişimdir, bu da her isteğin OAuth 2.0 akışı aracılığıyla izin vermiş kimliği doğrulanmış bir kullanıcıya bağlı olması gerektiği anlamına gelir. Bunun bir çözümü yoktur: API anahtarı yok, temel kimlik doğrulama yok (Eylül 2024'te kullanımdan kaldırıldı), sihirli bir başlık yok. Desteklenen üç kimlik doğrulama yolu şunlardır: OAuth 2.0 İstemci Kimliği (çok kiracılı), Etki Alanı Geniş Yetkilendirmeye Sahip Hizmet Hesabı (yalnızca Workspace) ve sizin için OAuth katmanını yöneten Unipile gibi birleşik bir e-posta API'si.
Google Cloud'da API anahtarı ile OAuth istemci kimliği arasındaki fark nedir?
Bir API anahtarı Faturalandırma ve kota amaçlı Google Cloud projenizi tanımlar. Yalnızca genel veriler sunan API'ler (Haritalar, Çeviri vb.) için çalışır. Bir OAuth istemci kimliği kullanıcı, uygulamalarınızın hesabınıza erişmesini onayladığı bir izin akışını başlatmak için kullanılır. OAuth istemci kimliği, Gmail API'nin aslında kabul ettiği erişim belirtecini ve yenileme belirtecini oluşturur. Bunlar tamamen farklı iki mekanizmadır: biri bir projeyi tanımlarken, diğeri bir kullanıcıyı kimliğini doğrular.
Bir hizmet hesabı kullanıcı rızası olmadan Gmail'i okuyabilir mi?
Sadece eğer Alan Geneli Yetkilendirme (DWD) bir Google Workspace yöneticisi tarafından etkinleştirilir. Hizmet hesabı tek başına hiçbir Gmail gelen kutusuna erişemez. DWD yapılandırılmış hizmet hesabı, kuruluş içindeki herhangi bir kullanıcının kimliğine bürünebilir ve etkileşimli onay olmadan posta kutularına erişebilir. Kritik sınırlama: bu yalnızca Google Workspace (işletme) hesapları için geçerlidir. Kişisel Gmail adreslerinde çalışmaz (@gmail.com). Bkz Google'ın resmi DWD belgeleri.
Gmail API, API anahtarım ile "Login Required" hatası neden veriyor?
Çünkü Gmail API, API anahtarlarını kabul etmez. Nokta 401 Giriş Gerekli hata, istekte geçerli bir OAuth 2.0 erişim jetonunun bulunmadığı anlamına gelir Authorization header. Gmail API şunu bekler: Yetkilendirme: Bearer {access_token} Erişim belirtecinin bir OAuth 2.0 akışı (yetkilendirme kodu, hizmet hesabı JWT veya birleşik API belirteci) aracılığıyla alındığı yer. Sadece ekleyerek ?anahtar=SENİN_API_ANAHTARIN Gmail API URL'si çalışmayacak ve 401 veya 403 döndürecektir.
Gmail API'yi kendiniz OAuth'u yönetmeden kullanmanın bir yolu var mı?
Evet. Birleşik bir e-posta API'si gibi Unipile Tüm OAuth katmanını yönetir: onay ekranı, belirteç değişimi ve sessiz yenileme belirteç döndürme. Uygulamanız hiçbir zaman erişim belirteçlerini veya yenileme belirteçlerini depolamaz veya yönetmez. Unipile API'sini kendi API anahtarınızla çağırırsınız ve Unipile, tüm OAuth iletişimini Google ile sizin adınıza yönetir bağlı hesaplar. Bu, kodunuzdan Google onay ekranı onay sürecini ve jeton yönetimi karmaşıklığını kaldırır ve Gmail, Outlook ve IMAP'ı tek bir birleşik arayüz altında sunar.
TR 
EN 
FR 
ES 
DE 
IT 
BR 
NL 
PL