LinkedIn
Instagram
WhatsApp
Telgraf
Google Takvim
Slack Topluluğuna KatılınOAuth E-posta API: Kullanıcı Posta Kutularını Kimlik Doğrulama Doğru Yol
Parolaları saklamayı bırakın. Bir OAuth e-posta API'si, uygulamanızın kullanıcı gelen kutularına güvenli bir şekilde erişmesini sağlar - Gmail, Outlook ve IMAP sağlayıcılarından geri alınabilir, kapsamı sınırlı jetonlar kullanarak. Bu kılavuz, her OAuth akışını, her kapsamı, her tuzağı ve birleşik barındırılan bir kimlik doğrulama katmanıyla 5 dakikada nasıl gönderileceğini kapsar.
// OAuth üzerinden herhangi bir kullanıcı posta kutusuna bağlanma - 1 API çağrısı
const response = bekliyor fetch(
'https://api6.unipile.com:13226/api/v1/hosted/accounts/link',
{
method: 'POST',
headers: {
'X-API-ANAHTARI': 'SENİN_API_ANAHTARIN',
'Content-Type': 'application/json'
},
body: JSON.stringify({
tip: 'Google', // veya MICROSOFT, IMAP
isim: 'kullanıcı_123'
})
}
);
const { url } = bekliyor cevap.json();
// Kullanıcıyı url'ye yönlendir - OAuth Unipile tarafından halledilir
OAuth E-posta API'si, e-postalarınıza programlı bir şekilde erişim sağlamak için kullanılan bir API'dir.
Bir OAuth e-posta API'si Uygulamanızın, kullanıcının parolasını asla işlemeden veya saklamadan, OAuth 2.0 belirteçlerini kullanarak kullanıcı posta kutularına erişimini sağlayan programatik bir arayüzdür. Kullanıcılardan kimlik bilgileri istemek yerine, onları sağlayıcının izin ekranından geçirir, kısa ömürlü bir erişim belirteci alırsınız ve bu belirteci onların adına e-posta okumak, göndermek veya senkronize etmek için kullanırsınız. Ayrım önemlidir: bu, erişimle ilgilidir kullanıcıya ait posta kutuları (Gmail, Outlook, kişisel e-posta), SendGrid gibi SMTP yönlendirme hizmetleri aracılığıyla işlem e-postaları göndermeme.
Bir OAuth e-posta API'si bir kullanıcının kimliğini doğrulamak ve yetkilendirilmiş erişim elde etmek için bir OAuth 2.0 yetkilendirme akışının (kullanıcının kimliğini doğrulamak ve yetkilendirilmiş erişim elde etmek amacıyla) ve bir e-posta API'sinin (kullanıcının posta kutusunu okumak, göndermek, aramak veya senkronize etmek için) birleşimidir. OAuth katmanı, kriptografik olarak imzalanmış, geri alınabilir, kapsamı sınırlı bir erişim belirteci oluşturur. E-posta API'si, kullanıcının şifresini asla bilmeden Gmail, Outlook veya herhangi bir IMAP uyumlu posta kutusuyla etkileşim kurmak için bu belirteci tüketir.
- Veritabanınızda düz metin veya şifrelenmiş parolaları saklar
- Tam posta kutusu erişimi - kapsam denetimi yok
- Google/Microsoft tarafından 2026'dan beri engellendi
- Kimlik bilgileri depolama için GDPR/SOC2 sorumluluğu
- Sıfır parola depolama - yalnızca kısa ömürlü jetonlar
- Ayrıntılı kapsamlar - salt okunur, yalnızca gönder, veya tam
- Kullanıcı tarafından herhangi bir zamanda iptal edilebilir
- GDPR uyumlu, SOC2
OAuth'ın Parola Tabanlı E-posta Erişimi Yerine Neden Geçtiği
Kullanıcı adı ve parola ile IMAP kullanmak, programatik olarak kullanıcı e-postalarına erişmenin standart yolu olmaktan çıktı. O dönem sona erdi. Google, 2022'de Gmail için temel kimlik doğrulamayı kullanımdan kaldırdı ve Microsoft, Exchange Online için temel kimlik doğrulama kapatmasını Ekim 2022'de tamamladı ve kalan protokoller için son temizlik 2026'da yapılacak. Uygulamanız hala parola tabanlı IMAP erişimine dayanıyorsa, ya zaten bozuktur ya da yakında bozulacaktır.
OAuth jetonları kısa ömürlüdür (tipik olarak 1 saat) ve kapsamla sınırlıdır. Sızdırılmış olsalar bile, kullanıcı olarak oturum açmak, şifrelerini değiştirmek veya diğer hizmetlere erişmek için kullanılamazlar. Kullanıcının kimlik bilgilerine asla dokunmazsınız.
Microsoft, Exchange Online ve eski IMAP için temel kimlik doğrulamasının kullanımını 2026'da emekliye ayırdı. Outlook veya Microsoft 365 posta kutularına erişmek için hala kullanıcı adı+şifre kullanan herhangi bir uygulama 401 Yetkisiz hataları alacaktır.
Kullanıcı parolalarını saklamak - hashlenmiş olsalar bile - yasal uyumluluk sorumluluğu yaratır. GDPR'nin veri en aza indirme ilkesi, ihtiyacınız olmayan verileri toplamamanızı gerektirir. SOC2 denetçileri kimlik bilgileri depolamasını işaretler.
Kritik Google Uygulama Parolaları ve Microsoft eski protokolleri artık üretim uygulamaları için yeterli değildir. Kullanıcı posta kutularına erişen bir ürün oluşturuyorsanız, bir OAuth e-posta API'si isteğe bağlı değildir - 2026'da ilerlemenin tek uyumlu yoludur.
E-posta API'leri İçin OAuth Nasıl Çalışır (Adım Adım)
Yetkilendirme kodu akışı, kullanıcı e-postasına erişmesi gereken sunucu taraflı uygulamalar için standart OAuth 2.0 akışıdır. Bunu uçtan uca anlamak, doğru bir şekilde uygulamanıza, jeton hatalarını ayıklamanıza ve akışı güvenlik ekibinize açıklamanıza yardımcı olur.
Bir URL'yi seninle birlikte oluşturursun client_id, bir yönlendirme_url'si, istenen kapsam, rastgele eyalet parametre (CSRF koruması) ve yanıt_türü=kod. Kullanıcı, Google veya Microsoft'un onay ekranına yönlendirilir.
Onay ekranı, uygulamanızın adını, logosunu ve istediğiniz tam izinleri gösterir. Kullanıcı onaylar (rıza gösterir) veya reddeder. Bu adımda çok fazla kapsam istemek, onayın reddedilmesinin en yaygın nedenidir.
Onaydan sonra, sağlayıcı sizi şuraya yönlendirir yönlendirme_url'si kısa ömürlü kod parametre (yaklaşık 10 dakika geçerlidir). Doğrulayın eyalet parametre, CSRF saldırılarını önlemek için gönderdiğinizle eşleşiyor.
Sunucudan sunucuya POST ile token uç noktasına, sizinle client_id, client_secret, the kodve grant_type=authorization_code. Bir alırsınız erişim_belirteci ve (çevrimdışı erişim istediyseniz) bir yenileme_belirteci.
Erişim belirtecini şurada iletin Yetkilendirme: Bearer Her API isteğinde başlık. Süresi dolduğunda (genellikle 1 saat sonra), kullanıcı etkileşimi olmadan yeni bir erişim belirteci almak için yenileme belirtecini kullanın.
Erişim jetonları ve yenileme jetonları: yaşam döngüsü
1 saat geçerlidir (Google) veya 1 saat (Microsoft). Her API çağrısında Authorization başlığında gönderilir. Süresi dolduğunda, OAuth e-posta API çağrınız 401 hatası döndürür - yenileme işareti budur.
İptal edilinceye kadar geçerli (Google) veya 90 gün etkinlik olmazsa geçersiz (Microsoft). API uç noktalarına asla gönderilmez - yalnızca yeni erişim belirteçleri almak için sunucudan sunucuya kullanılır. Beklemedeyken şifrelenmelidir.
Dakikalar içinde birleşik bir OAuth akışı oluşturun
Sağlayıcıya özel yetkilendirme yapılandırmasını atlayın. Tek Unipile API çağrısı, üç OAuth entegrasyonunun yerini alır.
Sağlayıcıya Göre OAuth Akışları: Google ve Microsoft
Google ve Microsoft OAuth 2.0'ı farklı şekilde uygular - farklı yetkilendirme uç noktaları, farklı kapsamlar, farklı belirteç uç noktaları ve farklı doğrulama süreçleri. IMAP, standart Oauth olmayan sağlayıcılar için parola tabanlı bir yedektir. İşte her durum için bilmeniz gerekenler.
Google'ın OAuth uygulaması standart yetkilendirme kodu akışını kullanır. Belirteç uç noktası https://oauth2.googleapis.com/token. Kritik karmaşıklık Google CASA'dır (Bulut Uygulaması Güvenlik Değerlendirmesi): uygulamanız 100 kullanıcıyı aştığında bir güvenlik incelemesinden geçmek zorundasınız. Hassas kapsamlar için, örneğin gmail.değiştir veya gmail.yalnızcaoku, Üretim aşamasında kullanımdan önce Uygulama Doğrulaması gereklidir. Tam bir Gmail API entegrasyonu derinlemesine inceleme, özel kılavuzumuza bakınız. Uygulama ayrıntıları şunlardır: Unipile Google OAuth belgeleri.
Gmail erişimi için # Exchange yetkilendirme kodu + yenileme jetonları
kıvrıl -X POST https://oauth2.googleapis.com/token \
-d "kod=AUTH_CODE" \
-d "client_id=SENIN_CLIENT_ID" \
-d "client_secret=GİZLİ_KODUNUZ" \
-d "yönlendirme_uygulaması=https://yourapp.com/callback" \
-d "grant_type=yetkilendirme_kodu"
# Yanıtı: { "access_token": "...", "refresh_token": "...", "expires_in": 3600 }
Microsoft Kimlik Platformu'nu (eski adıyla Azure AD v2) kullanır. Belirteç uç noktası https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token. Yayıncı Doğrulaması, OAuth e-posta API uygulamanızın üretimde hassas posta kapsamlarını istemeden önce gereklidir. Microsoft, tüm Exchange Online protokolleri için temel kimlik doğrulamayı kullanımdan kaldırdı - OAuth zorunludur. Bizimkilere bakın Microsoft Graph e-posta kılavuzunu tamamlayın tam ayrıntılar için ve Unipile Microsoft OAuth belgeleri uygulama referansı için.
Microsoft OAuth belirteçleri için # Dönüşüm kodu
kıvrıl -X POST https://login.microsoftonline.com/common/oauth2/v2.0/token \
-d "kod=AUTH_CODE" \
-d "client_id=SENIN_CLIENT_ID" \
-d "client_secret=GİZLİ_KODUNUZ" \
-d "yönlendirme_uygulaması=https://yourapp.com/callback" \
-d "grant_type=yetkilendirme_kodu" \
-d "kapsam=https://graph.microsoft.com/Mail.Read çevrimdışı_erişim"
# Yanıtı: { "access_token": "...", "refresh_token": "...", "expires_in": 3600 }
IMAP bir OAuth sağlayıcısı değildir; kullanıcı adı/parola veya uygulama parolaları (Google Uygulama Parolası veya iCloud tarafından oluşturulan parola gibi) ile kimlik doğrulaması yapan bir protokoldür. Microsoft 365'te olmayan özel posta sunucuları, kurumsal alanlar ve standartlaştırılmış bir OAuth akışı olmayan herhangi bir sağlayıcı için yedektir. XOAUTH2, az sayıda sağlayıcı için bir IMAP SASL uzantısı olarak mevcuttu, ancak büyük ölçüde terk edildi - Yahoo ilk taraf uygulamasını 2022'de kullanımdan kaldırdı. IMAP dağıtımlarının çoğu için Unipile, kimlik bilgileriyle doğrudan kimlik doğrulaması yapar. Tamamını görüntüleyin. IMAP entegrasyon kılavuzu sunucu yapılandırma ve kimlik doğrulama ayrıntıları için.
İthalat base64, imaplib
# OAuth erişim belirtecinden XOAUTH2 dizesi oluştur
fonksiyon build_xoauth2(kullanıcı_e_postası, erişim_jetonu):
auth_str = user={user_email}\x01auth=Bearer {access_token}\x01\x01"
return base64.b64encode(auth_str.encode()).decode()
# XOAUTH2 ile IMAP üzerinden bağlan
bağlan = imaplib.IMAP4_SSL("imap.mail.yahoo.com")
auth_str = build_xoauth2("user@yahoo.com", erişim_belirteci)
Bağlantı.kimlik doğrula("XOAUTH2", lambda x: kimlik_doğrulama_dizesi)Çoklu Sağlayıcılı OAuth'un Gizli Karmaşıklığı
Tek bir sağlayıcı için OAuth e-posta API'si uygulamak birkaç gün sürer. Gmail, Outlook ve IMAP için üretim düzeyinde belirteç yönetimi, hata işleme ve uyumluluk ile doğru bir şekilde uygulamak genellikle 4 ila 8 haftalık mühendislik süresi gerektirir. İşte nedeni.
Google Cloud Console, Azure Portal ve Yahoo Developer Network, farklı kullanıcı deneyimleri, farklı uygulama kayıt akışları ve farklı doğrulama gereksinimleri olan tamamen farklı 3 gösterge paneli. Herhangi bir kimlik bilgilerinin döndürülmesi 3'ünü de etkiler.
Gmail'in hassas kapsamları (dahil gmail.yalnızcaoku) CASA Seviye 2 değerlendirmesini geçene kadar 100 kullanıcı sınırında tutulur. Bu süreç, CASA onaylı bir laboratuvar çalışması, bir sızma testi ve resmi bir güvenlik incelemesini içerir; genellikle 6-12 hafta sürer ve maliyeti 10.000-25.000 Avustralya doları arasındadır.
Microsoft, hassas posta kapsamları isteyen uygulamalar için Yayıncı Doğrulaması gerektirir. Bu olmadan kullanıcılar, izin ekranında kırmızı bir "doğrulanmamış yayıncı" uyarısı görür. Doğrulama süreci, doğrulanmış bir etki alanına sahip aktif bir Microsoft Partner Network hesabı gerektirir.
Google yenileme jetonları 6 aylık bir süre boyunca işlem yapılmadığında sona erer (veya kullanıcı tarafından iptal edilirse hemen geçerliliğini yitirir). Microsoft jetonları 90 günlük hareketsizlikten sonra sona erer. Yahoo/IMAP XOAUTH2 jetonlarının sağlayıcıya özgü kullanım ömürleri vardır. Jeton yönetimi katmanınızın tüm 3'ünü farklı şekilde ele alması gerekir.
Google, Microsoft ve Yahoo, her biri onay ekranlarını farklı şekilde sunuyor - farklı markalaşma, farklı kapsam açıklamaları ve farklı kullanıcı arayüzü desenleri. Kullanıcılarınız e-posta sağlayıcılarına bağlı olarak 3 farklı akış görüyor, bu da tutarsız bir kullanıcı deneyimine ve daha yüksek terk oranlarına neden oluyor.
OAuth uç noktaları değişir. Kapsam adları kullanımdan kaldırılır. Yeni güvenlik gereksinimleri eklenir. Her sağlayıcı, farklı zaman çizelgelerinde geriye dönük uyumluluğu bozan değişiklikleri duyurur. Ekibinizden birinin 3 sağlayıcı blogunu, 3 değişiklik günlüğünü ve 3 uyumluluk takvimini takip etmesi gerekir - süresiz olarak.
Tüm OAuth karmaşıklığını atlayın
Barındırılan kimlik doğrulama, kapsam yönetimi, refresh yönetimi. Unipile bunların hepsini halleder, böylece siz ürününüze odaklanabilirsiniz.
OAuth E-posta API Mimarisi: Karşılaştırmalı 3 Yaklaşım
E-posta API katmanı oluşturmak için 3 farklı mimari vardır. Her birinin temelden farklı olarak gönderim maliyeti, bakım yükü ve güvenlik profili bulunur. Doğru seçim, e-posta bağlantısının ana ürününüz mü yoksa ana ürününüzle birlikte sunduğunuz bir özellik mi olduğuna bağlıdır.
| Boyut | Doğrudan Sağlayıcı OAuth (x3) | Kendi Kendine Barındırılan OAuth Ağ Geçidi | Birleşik Barındırılan OAuth (Unipile) Tavsiye edilir |
|---|---|---|---|
| İlk posta kutusuyla bağlantı süresi | 3-7 gün (sağlayıcı başına) | 2-4 hafta | 5 dakika |
| Uygulanacak OAuth akışları | 3 ayrı akış | 3 akış + yönlendirme mantığı | 1 barındırılan bağlantı uç noktası |
| Google CASA incelemesi | Sen hallet (6-12 hafta, $10k+) | Sen halledersin | Unipile Tarafından İşlem Yapıldı |
| Microsoft Publisher Doğrulama | Sen halledersin | Sen halledersin | Unipile Tarafından İşlem Yapıldı |
| Token yenileme yönetimi | İnşa etmek için 3 strateji | Sağlayıcıya özel | Otomatik, şeffaf |
| E-posta okuma/gönderme API'si | 3 farklı API | Soyutlama katmanı gerekli | 1 birleştirilmiş REST API |
| Yeni e-postalarda webhook | Sağlayıcı başına itme/çekme | Özel | Birleşik webhook olayları |
| SOC2 / GDPR uyumluluğu | Sizin sorumluluğunuz | Sizin sorumluluğunuz | Unipile SOC2 sertifikalıdır |
| Devam eden bakım | Yüksek (3 sağlayıcı değişiklik günlüğü) | Yüksek | Sıfır - Unipile tarafından halledildi |
| En iyisi | Tek tedarikçili, e-posta tabanlı ürünler | Özel altyapıya sahip büyük ekipler | Hızlı gönderim yapan herhangi bir takım |
Hazır Almak vs. Kendin Yapmak: 5 Dakikada Barındırılan OAuth E-posta API'si
3 ayrı OAuth akışı oluşturmak yerine Unipile, sizin için Google OAuth, Microsoft Identity ve IMAP OAuth'ı yöneten barındırılan bir kimlik doğrulama bağlantısı sunar. Uygulamanız bir bağlantı oluşturur, kullanıcıyı yönlendirir ve posta kutusu bağlandığında bir webhook alır. OAuth e-posta API'si hemen kullanılabilir hale gelir; konsol kurulumu, CASA incelemesi veya oluşturulacak jeton yenileme mantığı gerekmez.
Adım 1: Barındırılan bir kimlik doğrulama bağlantısı oluşturun
Konaklamalı bir kimlik doğrulama oturumu oluşturmak için tek bir API çağrısı. Sağlayıcı türünü ve hesap için bir ad belirtin. Unipile, kullanıcınızı OAuth onay ekranına yönlendirecek bir URL döndürür.
// Unipile'ın barındırılan OAuth e-posta API'si aracılığıyla Gmail kullanıcısını bağlayın
const response = bekliyor fetch(
'https://api6.unipile.com:13226/api/v1/hosted/accounts/link',
{
method: 'POST',
headers: {
'X-API-ANAHTARI': 'SENİN_UNIPILE_API_ANAHTARIN',
'Content-Type': 'application/json'
},
body: JSON.stringify({
tip: 'Google',
isim: 'kullanici_alice_123',
başarı_yönlendirme_url'si: 'https://uygulamam.com/bagli',
basarisiz_yonlendirme_url 'https://uygulamam.com/hata'
})
}
);
const { url, nesne } = bekliyor cevap.json();
// Kullanıcıyı url'ye yönlendir - Unipile, OAuth onayını yönetir
window.location.href = url;Adım 2: Bir Outlook kullanıcısı bağlayın
Aynı uç nokta, aynı düzen. Değiştir tip için MICROSOFT. Azure Portal yok, Publisher Verification'ı sizin tarafınızdan yönetmek yok.
İthalat istekleri
#, Unipile OAuth e-posta API'si aracılığıyla Outlook kullanıcısını bağlar
response = istemler.POST(
"https://api6.unipile.com:13226/api/v1/hosted/accounts/link",
başlıklar="X-API-ANAHTAR": "SENIN_UNIPILE_API_ANAHTARIN"},
json={
"tip": "MİKROSOFT",
"isim": "user_bob_456",
"başarı_yönledirme_url": "https://sizinkullanımınız.com/bagli"
}
)
auth_url = response.json()["url"]
# auth_url adresine yönlendirme - Unipile tarafından yönetilen Microsoft Kimlik akışıAdım 3: Hesaba bağlıyken webhook'u al
OAuth onayından sonra Unipile, uç noktanıza bir webhook gönderir. Olay yükü, yeni bilgileri içerir account_id - daha sonraki tüm işlemlerinizde kullandığınız ve sakladığınız e-posta oku API'si ve e-posta gönderme API'si aramalar.
Webhook olayı: Bir kullanıcı OAuth'u tamamladığında, Unipile şunları gönderir: hesap.bağlı tesine bir olay bilgisi gönderilir. Yük şunları içerir: account_id (bunu kaydet), the provider (GOOGLE / MICROSOFT / IMAP) ve bağlantılı e-posta adresi. Sürekli saklamanız gereken tek durum budur - Unipile tüm OAuth belirteçlerini dahili olarak yönetir.
8 haftalık OAuth uygulamasından kurtulun. Posta kutularınızı dakikalar içinde bağlayın.
Unipile'ın barındırılan OAuth e-posta API'si, Google CASA, Microsoft Publisher Verification, XOAUTH2 ve tüm sağlayıcılar için jeton yenileme işlemlerini yönetir. Kullanıcılarınız posta kutularını tek bir barındırılan akışla bağlar; siz de okuma, gönderme ve senkronizasyon için birleşik bir API elde edersiniz.
OAuth Token'larını Yönetme: Yenileme, İptal Etme, Döndürme
Token yönetimi, bir OAuth e-posta API'si oluşturmanın operasyonel olarak en zorlu kısmıdır. Erişim belirteçleri süresi dolar, yenileme belirteçleri kullanıcılar tarafından iptal edilir ve sisteminiz bunların tümünü zarif bir şekilde ele almalıdır, aksi takdirde kullanıcılarınızın posta kutularına sessizce erişimini kaybetme riskiyle karşı karşıya kalırsınız.
Token depolama için en iyi uygulamalar
- Dinlenme halindeyken yenileme jetonlarını AES-256 veya bir bulut KMS (AWS KMS, GCP Cloud KMS, Azure Key Vault) kullanarak şifreleyin. Asla veritabanınızda düz metin olarak saklamayın.
- Erişim belirteçlerini veya yenileme belirteçlerini asla günlüğe kaydetmeyin. Datadog veya Splunk gibi yapılandırılmış günlük sistemlerinde belirteç alanları maskelenmeli veya sansürlenmelidir.
- Veritabanı tehlikeye girerse etki alanını en aza indirmek için belirteçleri ana uygulama veritabanınızda değil, özel bir gizli anahtar deposunda (Vault, AWS Secrets Manager) saklayın.
- Token döndürmeyi uygulayın: yenileme çağrısında yeni bir yenileme belirteci aldığınızda (bazı sağlayıcılar her kullanımda yeni yenileme belirteçleri verir), eskisini hemen geçersiz kılın.
Yenileme hatalarını zarif bir şekilde ele alma
Yenileme belirtecinin süresi dolduğunda veya iptal edildiğinde, yenileme çağrınız 400 veya 401 hatası döndürür. OAuth e-posta API'niz bunu yakalamalı ve kullanıcı için sessizce başarısız olmak yerine yeniden kimlik doğrulama akışını tetiklemelidir. En kötü sonuç, e-postaların okunduğunu düşünen ancak belirteci haftalarca iptal edilmiş olan bir kullanıcıdır. Açık bir hesap sağlığı kontrolü oluşturun ve yeniden kimlik doğrulama gerektiğinde kullanıcılara uyarı verin.
OAuth Kapsamları: Neden İstenmeli (ve Neden İstenmemeli)
Kapsam en aza indirme hem bir güvenlik en iyi uygulaması hem de bir izin optimizasyon stratejisidir. İhtiyacınız olandan daha fazla kapsam istemek, kullanıcıların izin ekranında tereddüt etmesine (veya reddetmesine) neden olur ve Google CASA ile Microsoft Yayıncı incelemeleri sırasında artan bir incelemeyi tetikler.
| Kapsam | Sağlayıcı | Kullanım örneği | Hassasiyet | CASA incelemesi? |
|---|---|---|---|---|
| gmail.yalnızcaoku | Gmail | Tüm e-postaları ve meta verileri oku | Yüksek | Evet - Kademe 2 |
| gmail.gönder | Gmail | E-postayı kullanıcı olarak gönder | Yüksek | Evet - Kademe 2 |
| gmail.değiştir | Gmail | Oku, gönder, sil, etiketle | Yüksek | Evet - Kademe 2 |
| gmail etiketleri | Gmail | Etiketleri yalnızca oku ve yönet | Düşük | Hayır |
| Mail.Read | Görünüm | Tüm postaları oku | Orta | Yayıncı Doğrulaması |
| Mail.Gönder | Görünüm | Kullanıcı olarak e-posta gönder | Orta | Yayıncı Doğrulaması |
| Mail.ReadWrite | Görünüm | Oku, gönder, sil, klasör yönetimi | Yüksek | Yayıncı Doğrulaması |
| çevrimdışı_erişim | Görünüm | Yenileme belirteçleri al | Düşük | Hayır |
| posta-r | IMAP (Yahoo) | IMAP/XOAUTH2 ile e-posta oku | Orta | Yahoo geliştirici incelemesi |
Tokenleriniz yenilendi ve döndürüldü
Token yaşam döngüsü kodları yazmayı bırakın. Bir posta kutusunu yalnızca bir kez bağlayın, Unipile tüm sağlayıcılarda erişimi canlı tutar.
Uyumluluk: SOC2, GDPR, CASA
Kullanıcı posta kutularını yöneten bir OAuth e-posta API'si, güvenlik ve gizlilik uyumluluğunun kesişim noktasında yer alır. İşte kurumsal alıcıların en çok soracağı dört çerçeve ve OAuth'un jeton modeli bunların her biri için ne anlama geliyor.
SOC2 denetçileri, Erişilebilirlik ve Gizlilik kriterlerinin bir parçası olarak token kullanımını inceler. OAuth tokenları depolanırken şifrelenmeli (AES-256 veya KMS), erişim kayıtları tutulmalı ve resmi bir dönüştürme politikasına tabi tutulmalıdır. Yenileme tokenlarını düz metin olarak saklamak otomatik olarak bir bulgudur. SOC2 sertifikalı Unipile gibi barındırılan bir OAuth e-posta API'si kullanmak bu sorumluluğu devralır.
GDPR uyarınca, kullanıcı e-posta içeriklerine eriştiğinizde uygulamanız bir veri işleyicidir. OAuth e-posta API altyapı sağlayıcınızla bir DPA'ya (Veri İşleme Sözleşmesi) ihtiyacınız var. OAuth'un geri alınabilirliği, 17. Maddeyi (silme hakkı) doğrudan karşılar - bir kullanıcı geri aldığında, erişiminiz hemen sona erer. E-posta verilerine erişmeniz için yasal dayanağınızı belgeleyin (tipik olarak OAuth akışı aracılığıyla alınan onay).
Gmail OAuth e-posta API uygulamanızın hassas erişim kapsamlarına sahip kullanıcı sayısı 100'ü aştığında, CASA Seviye 2'yi geçene kadar Google yeni kullanıcı eklemelerini engeller. Bunun için CASA tarafından yetkilendirilmiş bir laboratuvar tarafından gerçekleştirilecek bir sızma testi, bir güvenlik anketi ve Google'a sunulacak resmi bir değerlendirme raporu gereklidir. Süre: 8-16 hafta. Maliyet: 10.000-25.000 TP4T. Doğrulanmış uygulamalar, onay ekranında "Google tarafından doğrulanmıştır" rozetini alır.
OAuth E-posta API: Fiyatlandırma ve Maliyet Modelleri
Google ve Microsoft'un "ücretsiz" servis sağlayıcı API'leri önemli gizli maliyetler barındırıyor. Ölçekte bir OAuth e-posta API'si uygulamak için gerçekçi bir maliyet modeli aşağıdadır - doğrudan servis sağlayıcı rotası ve birleşik API'ler kapsanmaktadır.
Google ve Microsoft API'leri, API çağrısı düzeyinde teknik olarak ücretsizdir. Ancak: Google CASA Tier 2, 10.000–25.000 TP4T ve 3 aydan fazla mühendislik süresi gerektirir. Microsoft için Yayıncı Doğrulaması, bir Partner Network hesabı ve yasal alan adı doğrulaması gerektirir. 3 akışın oluşturulması, jeton yönetimi ve hata işleme için gereken mühendislik süresi: 6–10 hafta. Yıllık bakım: sağlayıcı başına yılda 2–4 hafta.
Unipile'un OAuth e-posta API'si, tek bir abonelik altında tüm sağlayıcı uyumluluklarını (CASA, Yayıncı Doğrulaması), belirteç yönetimini ve birleşik bir e-posta API'sini içerir. E-posta bağlantısını bir özellik (ürün değil) olarak sunan ekipler için yatırım getirisi hesaplaması basittir: haftalarca mühendislik zamanından tasarruf edin ve aylık API maliyeti. Bakınız E-posta API sağlayıcılarını karşılaştırın Tam maliyet dökümü rehberi.
OAuth E-posta Uygulaması Uygularken Sık Yapılan Hatalar
Geliştiricilerin bir OAuth e-posta API'si oluştururken ilk kez yaptığı en yaygın hatalar şunlardır - ve bunun yerine ne yapılmalı.
Google, kullanıcı uygulamalarınızı 6 aydır kullanmadığında yenileme jetonlarını geçersiz kılar. Jeton yenileme çağrınız şunları döndürür: geçersiz_hibe. Düzeltme: E-posta etkisizliği nedeniyle hesabın sona ermesini önlemek için bağlı her hesap için en az 30 günde bir hafif bir Gmail API çağrısı yapan periyodik bir "token sağlık kontrolü" uygulayın.
Talep ediliyor gmail.değiştir sadece ihtiyacın olduğunda gmail.yalnızcaoku izin isteme ekranınızı şişirir ve kullanıcıların OAuth akışından vazgeçmesine neden olur. Ayrıca CASA kota gereksinimini artırır. Her zaman minimum gerekli kapsamı isteyin. Daha sonra artımlı olarak ek kapsamlar isteyebilirsiniz.
Gmail'in hassas kapsam sınırı olan 100 kullanıcı, OAuth e-posta API uygulamaları için en yaygın büyüme engelleyicisidir. 50 kullanıcıya ulaşmadan CASA incelemesi için plan yapın - inceleme 8-16 hafta sürer ve beklerken kullanıcı büyümeniz engellenecektir.
Yetkili başlıkları yakalayan ayrıntılı istek günlüğü, erişim belirteçlerinizi düz metin olarak günlüğe kaydedecektir. Bu nedenle, günlüğün temizlenmesi için bir ara yazılım uygulayın. Taşıyıcı [TOKEN] herhangi bir kalıcı depolama alanına yazılmadan önce günlüklerdeki desenler.
Bazı kurumsal e-posta sunucuları, OAuth'u desteklemeyen özel IMAP yapılandırmalarının arkasında çalışır. OAuth e-posta API'nizin yalnızca IMAP kullanan sağlayıcılar için zarif bir geri çekilme yolu olmalıdır. Bunu en başından itibaren hesap bağlantı akışınıza dahil edin, aksi takdirde önemli bir B2B kullanıcı kesimini dışlamış olursunuz. Bizimkinizi görün IMAP entegrasyonu Tam yedekleme deseni için kılavuz.
Birleştirme sağlayıcıları yerine inşa etme
Bugün çalışan bir OAuth e-posta entegrasyonu edinin. Ücretsiz katman, kredi kartı gerekmez, tam Gmail ve Microsoft kapsamları mevcuttur.
Sıkça Sorulan Sorular
Bir geliştiricinin bir OAuth e-posta API entegrasyonu oluştururken en sık sorduğu sorular - kesin yanıtlarıyla.
https://oauth2.googleapis.com/token, alanlar, içindeki gmail.* Outlook (Outlook.com, Microsoft 365 ve Exchange Online'ı kapsayan) için ad alanı: Microsoft Identity Platform, belirteç uç noktası https://login.microsoftonline.com/common/oauth2/v2.0/token, kapsamları altında https://graph.microsoft.com/. IMAP için: IMAP bir OAuth sağlayıcısı değildir. Kullanıcı adı/parola veya uygulama parolası kimlik bilgileri kullanır. XOAUTH2, az sayıda sağlayıcı için bir SASL uzantısı olarak var olsa da büyük ölçüde kullanımdan kaldırılmıştır.grant_type=refresh_token. Google için: POST et https://oauth2.googleapis.com/token. Microsoft için: POST to https://login.microsoftonline.com/common/oauth2/v2.0/token. Alırsanız geçersiz_hibe, Yenileme belirteci süresi dolmuş veya geçersiz kılınmış - kullanıcıyı yeniden kimlik doğrulamaya yönlendirin.gmail.yalnızcaoku okumak, gmail.gönder göndermek, gmail.değiştir Tam okuma/yazma/silme. Outlook için: Mail.Read okumak, Mail.Gönder göndermek, Mail.ReadWrite tam erişim için - plus çevrimdışı_erişim yenileme jetonları almak için. Kulanım senaryonuzun gerektirdiği en az kapsamı her zaman isteyin. Bkz. E-posta API sayfası kullanım durumu özel kapsam önerileri için.gmail etiketleri (CASA'ya tabi değil), 50 kullanıcıya ulaşmadan önce CASA sürecini başlatın (8-16 hafta sürer) veya altyapısı CASA incelemesinden geçmiş Unipile gibi barındırılan bir OAuth e-posta API'sini kullanın - bu gereksinimi uygulamanız için tamamen ortadan kaldırır./api/v1/hosted/accounts/link. Geçiyorsun tip (GOOGLE, MICROSOFT veya IMAP) ve Unipile barındırılan bir kimlik doğrulama URL'si oluşturur. Kullanıcı, Google CASA ve Microsoft Publisher Verification'dan geçmiş olan Unipile'ın altyapısında OAuth onayını tamamlar. Onaydan sonra Unipile, bize bir webhook gönderir account_id. Tüm jeton yönetimi ve yenilemesi dahili olarak halledilir.geçersiz_hibe. OAuth e-posta API'niz bunu yakalamalı, bağlı hesabı bağlantısı kesilmiş olarak işaretlemeli ve kullanıcıyı yeniden kimlik doğrulama bağlantısıyla bilgilendirmelidir. Unipile ile bir iptal webhook'u otomatik olarak tetiklenir, böylece sisteminiz gerçek zamanlı olarak bilgilendirilir - yoklama gerekmez.
TR 
EN 
FR 
ES 
DE 
IT 
BR 
NL 
PL