Google, Google Sync ve yalnızca parola kullanan uygulama desteğini sonlandırıyor
(workspaceupdates.googleblog.com)- Google Workspace, yalnızca kullanıcı adı ve parola paylaşarak oturum açmaya dayalı Less Secure Apps (LSA) yöntemini sonlandırıyor ve e-posta, takvim ve kişi senkronizasyonu için OAuth tabanlı oturum açma gerektiriyor
- Sonlandırma takvimi 15 Haziran 2024 ve 30 Eylül 2024 olmak üzere iki aşamada başlamıştı; ancak dağıtımın duraklatılıp yeniden başlatılmasının ardından 1 Mayıs 2025 itibarıyla LSA artık desteklenmiyor
- Yalnızca parola kullanan CalDAV, CardDAV, IMAP, SMTP, POP bağlantıları ve Google Sync bu değişiklikten etkileniyor; hem yeni hem de mevcut Google Sync kullanıcıları geçiş kapsamına giriyor
- Yöneticiler, etkilenen kullanıcılara OAuth’a geçiş yönergelerini iletmeli; MDM ile dağıtılan parola tabanlı profiller de Google Account’u OAuth ile yeniden ekleme yöntemine dönüştürülmeli
- Son tarihe kadar işlem yapmayan kullanıcılar, kullanıcı adı-parola kombinasyonu hatası nedeniyle oturum açamayacak; geliştiriciler de Workspace uyumluluğu için uygulama bağlantı yöntemini OAuth 2.0 olarak güncellemek zorunda
Yalnızca parola ile oturum açma yönteminin sonlandırılması
- Google Workspace, üçüncü taraf uygulama veya cihazların Google kullanıcı adı ve parolasını doğrudan istemesine dayalı oturum açma yöntemini artık desteklemiyor
- Bu yöntem Less Secure Apps (LSA) olarak adlandırılıyor; Google hesabı kimlik bilgilerinin üçüncü taraf uygulama ve cihazlarla paylaşılmasını gerektirdiği için hesaba izinsiz erişim riskini artırıyor
- Alternatif yöntem Sign in with Google; çoğu üçüncü taraf uygulama ve cihazın zaten kullandığı endüstri standardı kimlik doğrulama yöntemi olan OAuth’u kullanıyor
- Google bu değişikliği 2019’da duyurmuş, ardından uygulama takvimini yeniden paylaşmıştı
Sonlandırma takvimi ve erteleme geçmişi
- LSA erişiminin sonlandırılması başlangıçta iki aşamadan oluşuyordu
- 15 Haziran 2024 itibarıyla Admin Console’daki LSA ayarı kaldırıldı ve artık değiştirilemez hale geldi
- Daha önce etkinleştirilmiş kullanıcılar bağlantı kurmaya devam edebilirken, devre dışı bırakılmış kullanıcılar LSA’ya erişemedi
- Gmail, Google Calendar ve Contacts’a yalnızca parolayla erişen CalDAV, CardDAV, IMAP, SMTP, POP tabanlı üçüncü taraf uygulamalar buna dahildi
- Kullanıcıların Gmail ayarlarındaki IMAP etkinleştirme/devre dışı bırakma ayarı da kaldırıldı
- Bu tarihten önce LSA kullanan kullanıcılar, başlangıçtaki plana göre 30 Eylül 2024’e kadar kullanmaya devam edebilecekti
- 30 Eylül 2024 itibarıyla tüm Google Workspace hesaplarında LSA erişiminin kapatılması planlanmıştı
- CalDAV, CardDAV, IMAP, POP ve Google Sync, yalnızca parolayla oturum açıldığında artık çalışmayacaktı
- Kullanmaya devam etmek için daha güvenli erişim yöntemi olan OAuth ile oturum açmak gerekiyordu
- Sonrasında takvim birkaç kez değiştirildi
- 15 Ekim 2024 güncellemesinde dağıtım yıl sonuna kadar duraklatıldı ve Ocak 2025’te yeniden başlatılması planlandı
- 27 Ocak 2025 güncellemesinde dağıtım yeniden başlatıldı ve nihai devre dışı bırakma Mart 2025 için planlandı
- 12 Şubat 2025 güncellemesinde LSA desteğinin bitiş tarihi 14 Mart 2025 olarak değiştirildi
- 29 Nisan 2025 güncellemesinde LSA’nın 1 Mayıs 2025 itibarıyla artık desteklenmeyeceği belirtildi
Google Sync kullanan kuruluşlar için kontrol noktaları
- Bu değişiklik Google Sync’in sonlandırılmasını da içeriyor
- Google Sync’in başlangıçtaki sonlandırma takvimi şöyleydi
- 15 Haziran 2024 itibarıyla yeni kullanıcılar Google Sync üzerinden Google Workspace’e bağlanamaz
- 30 Eylül 2024 itibarıyla mevcut Google Sync kullanıcıları da Google Workspace’e bağlanamaz
- Kuruluş içinde Google Sync kullanılıp kullanılmadığı Admin Console’dan kontrol edilebilir
- Yol: Devices > Mobile & Endpoints > Devices
- Filtre: Type: Google Sync
Yöneticiler ve MDM yapılandırmaları üzerindeki etkiler
- Yöneticiler, son kullanıcıların Google Workspace hesaplarıyla uygulamaları kullanmaya devam edebilmesi için OAuth tabanlı erişim yöntemine geçmelerini sağlamalı
- Etkilenen kullanıcı bilgileri önümüzdeki birkaç ay içinde kuruluşlara e-posta ile sağlanacak
- IMAP, CalDAV, CardDAV, POP, Exchange ActiveSync (Google Sync) profillerini MDM sağlayıcılarıyla yapılandıran kuruluşlar da etkileniyor
- 15 Haziran 2024’ten itibaren parola tabanlı IMAP, CalDAV, CardDAV, SMTP, POP, Exchange ActiveSync (Google Sync) MDM push işlemleri, LSA’ya ilk kez bağlanmaya çalışan müşteriler için çalışmaz
- Google Endpoint Management kullanılıyorsa CalDAV ve CardDAV için Custom Push Configuration ayarı açılamaz
- 30 Eylül 2024’ten itibaren mevcut kullanıcılar için parola tabanlı IMAP, CalDAV, CardDAV, SMTP, POP push işlemleri çalışmaz
- Yöneticiler, MDM sağlayıcılarını kullanarak Google Account push etmelidir; bu yöntem iOS cihazlarına Google hesabını OAuth ile yeniden ekler
- Parola tabanlı Exchange ActiveSync (Google Sync) push işlemleri de mevcut kullanıcılar için çalışmaz
- Google Endpoint Management’taki “Custom push configuration-CalDAV” ve “Customer push configuration-CardDAV” ayarları geçerliliğini yitirir
Cihaz, uygulama ve geliştirici bazında geçiş yöntemleri
- Bir tarayıcı ya da başka bir cihaz SMTP veya LSA ile e-posta gönderiyorsa aşağıdakilerden biri gerekir
- OAuth kullanımını yapılandırmak
- Alternatif bir yöntem kullanmak
- İlgili cihaz için uygulama parolası yapılandırmak
- Yalnızca kullanıcı adı ve parolayla Google hesabına erişen uygulamalar için geçiş işlemi gerekir
- Son tarihe kadar işlem yapılmazsa kullanıcı adı-parola kombinasyonunun doğru olmadığına dair hata gösterilir ve oturum açılamaz
- E-posta uygulamalarına göre yapılacaklar
- Outlook 2016 veya önceki sürümlerden Microsoft 365, Outlook for Windows ya da Outlook for Mac’e geçilmelidir; bunlar OAuth erişimini destekler
- Alternatif olarak Google Workspace Sync for Microsoft Outlook kullanılabilir
- Thunderbird veya başka e-posta istemcilerinde Google hesabı yeniden eklenmeli ve IMAP OAuth ile yapılandırılmalıdır
- iOS veya macOS Mail uygulaması ya da Outlook for Mac’te yalnızca parolayla oturum açılıyorsa hesap kaldırılmalı, ardından yeniden eklenmeli ve “Sign in with Google” seçilmelidir
- Takvim ve kişi uygulamaları da OAuth destekleyen yöntemlere geçirilmelidir
- Parola tabanlı CalDAV takvim uygulamaları OAuth destekleyen bir yönteme dönüştürülmelidir; Google, Google Calendar uygulamasını önerir
- iOS veya macOS takvim uygulamasında yalnızca parolayla oturum açılıyorsa hesap kaldırılmalı, ardından yeniden eklenmeli ve “Sign in with Google” seçilmelidir
- iOS veya macOS’ta kişiler CardDAV ile senkronize ediliyor ve yalnızca parolayla oturum açılıyorsa hesap kaldırılıp yeniden eklenmeli ve “Sign in with Google” seçilmelidir
- Diğer platform veya uygulamalarda yalnızca CardDAV ve parola kullanılıyorsa OAuth destekleyen bir yönteme geçilmelidir
- OAuth’u desteklemeyen uygulamalar, OAuth sunan uygulamalarla değiştirilmeli veya erişim için uyygulama parolası oluşturulmalıdır
- Geliştiriciler, Google Workspace hesaplarıyla uyumluluğu sürdürmek için uygulama bağlantı yöntemini OAuth 2.0 olarak güncellemelidir
Kişisel Google hesapları ve kapsam
- Kişisel Google hesabı kullanıcıları için Gmail ayarlarında IMAP etkinleştirme/devre dışı bırakma anahtarı kaldırılacak
- Kişisel hesaplarda IMAP erişimi OAuth üzerinden her zaman etkin durumdadır ve mevcut bağlantılar etkilenmez
- Kişisel Google hesabı kullanıcılarının ayrıca işlem yapması gerekmez
- Bu değişiklik tüm Google Workspace müşterileri için geçerlidir
1 yorum
Hacker News yorumları
Bunu okuyunca bir an içim cız etti — çünkü Gmail ile entegre çalışan birkaç betiğim ve aracım var.
Yine de sorun yok gibi görünüyor. Uygulama şifreleri çalışmaya devam ediyor gibi; bu değişiklik daha çok hesabın normal kullanıcı adı/şifresini kullanan Less Secure Apps desteğinin kaldırılması gibi.
Google, OAuth dışındaki her şeyi gerçekten ortadan kaldırırsa ne kadar çok otomasyonun öleceğini düşünmek bile ürkütücü.
OAuth’un karmaşıklığından hoşlanmıyorum ve bu Perl modülü belgesinin yapıyı açıklama biçimini beğendim. Belli ki benim gibi sinir olmuş biri yazmış: https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Aut...
Benzer bir sorun yaşamıştım ve bir Workspace’te uygulama şifreleri engellenmişti. Küçük bir Python betiğiyle OAuth token alıp bunu şifre gibi kullanmak yeterli: https://github.com/google/gmail-oauth2-tools/blob/master/pyt...
Örnek için bkz. https://github.com/lefcha/imapfilter/issues/186
Şu anda ana Gmail hesabımın, diğer birkaç Gmail hesabının kimlik bilgileriyle SMTP gönderimi yapabilmesi için LSA anahtarını sürekli açık tutmam gerekiyor. Gmail’in diğer Gmail hesaplarının gözünde neden LSA olduğunu anlamıyorum.
16 küçük harften oluşuyor, 4’er karakterlik gruplar halinde boşluklarla ayrılıyor; rakam da özel karakter de yok.
Keepass, boşluklar kaldırıldığında bunu 65 bit entropili zayıf bir şifre olarak değerlendiriyor.
Bunun nasıl bir iyileştirme olduğunu anlamıyorum.
OAuth’a geçemiyorsanız, benim proxy’mi kullanarak OAuth 2.0’ı doğrudan desteklemeyen IMAP/POP/SMTP istemcilerini de “modern” e-posta sağlayıcılarıyla kullanabilirsiniz: https://github.com/simonrob/email-oauth2-proxy
İstemcinin OAuth hakkında hiçbir şey bilmesine gerek yok.
OAuth’a geçemiyorsanız bir uygulama şifresi oluşturup bunu her zamanki gibi IMAP şifresi olarak kullanmaya devam edebilirsiniz.
IMAP, SMTP ve POP; Google hesabına ve genel olarak hayata hatırı sayılır erişim hakkı verdiği halde iki aşamalı doğrulama yapmanın bir yolu olmadığı ve bot önleme doğrulaması da sunmadığı için.
Bu yüzden kimlik bilgisi deneme saldırıları çok kolaylaşıyor ve Google ölçeğinde bu tür saldırılar birçok insanın hayatını mahvedebilir.
Bu iyi bir değişiklik ve yıllar önce yapılmalıydı. Aslında IMAP/POP/SMTP erişiminin varsayılan olarak devre dışı bırakılması gibi yollarla bir ölçüde zaten yapılmıştı ve çoğu kullanıcı bununla korunuyor. Bu adım geriye kalan kullanıcılar için.
Dovecot’ta tercih ettiğiniz kimlik doğrulama modülünü seçip girilen şifreyi
pwd+otp codeolarak okuyacak şekilde değiştirmeniz yeterli. Kullanıcı iki aşamalı doğrulamayı açtıysa son 6 haneyi okuyup TOTP ile karşılaştırırsınız.Eşleşirse o IP’ye x dakika izin verir ya da istediğiniz politikayı uygularsınız.
Şaşırtıcı derecede iyi çalışıyor.
O adres Gmail olmayan ve IMAP/POP’a hâlâ izin veren bir yer olmalı. Her derde deva değil ama bazı kullanım senaryoları için kabul edilebilir bir geçici çözüm olabilir.
Bu, kullanıcıları mükemmel yerel e-posta uygulamalarından çıkarıp Google’ın kendi uygulamasına yönlendirme girişimi.
gmail.app ya da yakında kaldırılacak Google Sync olmadan gerçek zamanlı e-posta bildirimleri alamıyorsunuz. Hoşuma gitmiyor. Workspace’e para ödüyor olsam da hoşuma gitmiyor. Masaüstünde Mimestream hâlâ çalışıyor ama sanırım sırada o da hedef alınacak.
JMAP iyi bir standart protokol; ancak e-posta sağlayıcıları ile e-posta uygulamaları arasındaki tavuk-yumurta sorunu yüzünden benimsenme oranı akıl almaz derecede düşük. Gmail JMAP’i desteklerse, geliştiricileri her yerde destek eklemeye teşvik edebilir. JMAP bildirimleri ve başka işlevleri de destekliyor.
E-posta için OAuth, e-posta kimlik doğrulamasıyla ilgili çeşitli RFC’lerde yer alıyor ve yıllardır mevcut.
Thunderbird ve birçok mobil uygulama OAuth kullanarak Gmail’i gayet iyi destekliyor. Daha büyük sorun, birçok masaüstü uygulamasının yaklaşık 10 yıl önce IMAP ve SMTP değişikliklerini uygulamayı bırakmış gibi görünmesi.
Artık bakımı yapılmayan bir e-posta uygulamasıysa, Google’ın bağlantılı yazıda belirttiği gibi uygulamaya özel parolalar kullanılabilir. Bunlar çalışmaya devam ediyor. Ortadan kalkan şey, ana hesabın sabit kodlanmış kullanıcı adı/parola yöntemi.
Office 2016 kullanıcıları için büyük bir baş ağrısı olacak. Çünkü 30 Eylül, Outlook desteğinin sona ermesinden hâlâ yaklaşık 9 ay önceye denk geliyor. Ama çoğu kullanıcı için oldukça kolay bir düzeltme olacak gibi.
E-posta asenkrondur; bir iletinin geldiğini 10 dakika sonra öğrenmek sorun olmamalı. Beklediğim bir e-postaysa zaten gelene kadar yenile tuşuna basıp dururum.
Daha acilse mesaj atsınlar. Aramasınlar lütfen. Telefonu sevmiyorum.
“Uygulama şifresi, daha az güvenli bir uygulama veya cihaza Google Hesabınıza erişim izni veren 16 haneli bir paroladır ve yalnızca 2 Adımlı Doğrulama’nın açık olduğu hesaplarda kullanılabilir” diye açıklanıyor: https://support.google.com/mail/answer/185833
“Daha az güvenli uygulama veya cihaz” denilen şeyin, Google’ın eskiden beri teşvik edebileceği sunucu tarafı mekanizmaları kullanması hâlinde OAuth destekli uygulamalarla güvenlik açısından neredeyse eşdeğer hâle gelmesi komik değil mi? Teknik olarak uygulamanın bir özelliği bile değilmiş gibi görünüyor.
Elbette “güvenli iş akışı daha az kullanışlı olan uygulama” demek pek anlaşılır olmazdı, bu yüzden sadeleştirmenin haklı görülebileceği söylenebilir. Daha büyük sorun, Google’ın güvenlik kaygılarını her zaman kendi gündemine yarayacak biçimde yorumlama eğiliminde olması ve bu parçanın da istisna olmaması.
Şimdi yalnızca OAuth’u destekleyecek şekilde güncellenemeyen uygulamalar için bunu zorunlu kılıyor.
Uygulama parolaları işlevsel olarak ya her şeye izin ver ya da her şeyi engelle mantığına yakın; OAuth’ta ise okuma, değiştirme, ayar değiştirme gibi izinler yapılandırılabiliyor.
Android’de Google OAuth2’nin en sinir bozucu yanı, bir e-posta istemcisine veya takvime Google hesabıyla giriş yapmak için tüm telefonun o Google hesabına bağlanmasının gerekmesi.
Ayrıca o Google hesabı cihaz politikası yetkilerine de sahip oluyor. Bana göre bu tamamen saçma.
Uygulama içi WebView’de OAuth2 kullanmayı da Android’de Google kolayca kısıtlayabildiği için bunu aşmak zor.
Ne yazık ki güvenilir e-posta istemcisi çok değil. Birçoğu kimlik bilgilerini uzak sunuculara gönderiveriyor.
Düzeltme: k9 zaten IMAP için OAuth’u destekliyor.
https://docs.k9mail.app/en/6.400/accounts/incoming_imap/
İfade biraz muğlak, ama uygulamaya özel parolalar çalışmaya devam edecek gibi görünüyor.
Alıntıda, SMTP ya da LSA ile e-posta gönderen tarayıcı ve cihazların OAuth kullanacak şekilde yapılandırılması, alternatif bir yöntem kullanması ya da cihaz için uygulama parolası ayarlaması gerektiği yazıyor.
Ayrıca OAuth’u desteklemeyen uygulamalar için OAuth sağlayan bir uygulamaya geçilmesi ya da erişim için uygulama parolası oluşturulması gerektiği belirtiliyor.
Bu yüzden dün doğrudan Google Workspace Support’a sordum; yanıt “uygulama parolaları IMAP, POP ve tüm SMTP yapılandırmalarını destekler” oldu.
İkinci cümle OAuth benimsenmesini zorlamaya devam eden bir ifadeydi. Ben de bunu isterdim, ama tekrarlanan güvenlik incelemesi maliyetleri bizim gibi küçük bir SaaS uygulaması için karşılanabilir değil; bu yüzden neyse ki uygulama parolalarını kullanmaya devam edeceğiz.
Bu, Workspace hesapları ile ilgili; normal Gmail hesapları için bu değişiklik birkaç yıl önce zaten uygulanmıştı
Hâlâ kişisel Gmail hesabıma iPhone’daki Mail.app üzerinden Microsoft Exchange seçeneğiyle erişiyorum ve Fetch’e bağlı kalmadan bu yöntemle push bildirimleri alıyorum
Çalışmasının nedeni, yaklaşık 10 yıl önceki kapatma tarihinden önce kişisel hesapla Google Sync’te oluşturulan bağlantının hâlâ korunması ve “kazanılmış hak” gibi tanınması
Bu yüzden çalıştırmak için iPhone’un Exchange GUID’sini, yeni oturum açmalar durdurulmadan önce Google Sync’e giriş yapmış olan o zamanki telefonun GUID’siyle değiştirmeniz yeterli
Neyse ki iPhone yedeği oluşturup yedek içindeki plist dosyasını düzenledikten sonra geri yükleyerek bu GUID değişikliği yapılabiliyor
Şu anda da iPhone 14 Pro’da kişisel Gmail hesabım için Mail.app ve push bildirimleri kullanıyorum
Duyuru metninden anladığım kadarıyla uygulama parolaları bir süre daha korunacak. Ancak Google bir gün uygulama parolalarını da kaldırırsa, OAuth istemcilerinin masrafı kendileri karşılayarak güvenlik değerlendirmesi yaptırması gereken yapı nedeniyle Gmail’de üçüncü taraf istemci kullanımı ciddi ölçüde kısıtlanacak
E-posta hâlâ yaygın kullanılan son “açık mesajlaşma protokollerinden” biri ve istemci seçme imkânı var; böyle bir gidişat üzücü olur
Şirkette Microsoft’un OAuth geçişiyle uğraşıyorum ve epey baş ağrıttı
Sorunun bir kısmı bunun fazlasıyla opak olmasında. Token gönderince sunucu ek açıklama yapmadan sadece “hayır” diyor
Client Credentials akışının neden çalışmadığını anlamaya çalışarak günler harcadım ve sonunda yardım forumlarının derinliklerinde “ha, client credentials flow henüz desteklenmiyor” yanıtını buldum. Şu anda IMAP/POP için destekleniyor, ama hatırladığım kadarıyla SMTP için hâlâ değil. Öte yandan SMTP’de OAuth henüz zorunlu değil
Sonraki iş doğru scope (kapsam) değerini bulmaktı; o dönemde dokümantasyonu pek iyi değildi. Sunucunun hata mesajları da hiç yardımcı olmuyor
Google posta sunucuları biraz daha iyi mi?
Ne yazık ki sunucu, kimliği doğrulanmamış istemcilere “yardımcı” bilgi verme lüksüne sahip değil