Google、Google Syncとパスワード専用アプリのサポートを終了
(workspaceupdates.googleblog.com)- Google Workspaceは、ユーザー名とパスワードだけを共有してログインする Less Secure Apps(LSA) 方式を終了し、メール・カレンダー・連絡先の同期に OAuthベースのログイン を要求する
- 終了日程は2024年6月15日と9月30日の2段階で始まったが、ロールアウトの一時停止と再開を経て、2025年5月1日 からLSAはサポートされなくなった
- パスワードのみを使うCalDAV、CardDAV、IMAP、SMTP、POP接続と Google Sync が影響を受け、新規・既存のGoogle Syncユーザーの両方が移行対象に含まれる
- 管理者は影響を受けるユーザーにOAuth移行ガイドを共有する必要があり、MDMで配布していたパスワードベースのプロファイルも Google AccountをOAuthで再追加 する方式に切り替える必要がある
- 終了日までに対応しなかったユーザーは、ユーザー名とパスワードの組み合わせエラーによりログインできなくなり、開発者はWorkspace互換性のためにアプリ接続方式を OAuth 2.0 に更新する必要がある
パスワード専用ログイン方式の終了
- Google Workspaceは、サードパーティ製アプリやデバイスがGoogleのユーザー名とパスワードを直接要求するログイン方式を今後サポートしない
- この方式は Less Secure Apps(LSA) と呼ばれ、Googleアカウントの認証情報をサードパーティ製アプリやデバイスと共有する必要があるため、アカウントへの不正アクセスのリスクを高める
- 代替方式は Sign in with Google であり、ほとんどのサードパーティ製アプリやデバイスですでに使われている業界標準の認証方式であるOAuthを利用する
- Googleはこの変更を2019年に発表し、その後、適用日程を改めて公開した
終了スケジュールと延期の経緯
- LSAアクセスの終了は当初2段階で構成されていた
- 2024年6月15日 からAdmin ConsoleのLSA設定が削除され、以後は変更できなくなった
- すでに有効化されていたユーザーは引き続き接続できるが、無効化されていたユーザーはLSAにアクセスできない
- Gmail、Google Calendar、ContactsにパスワードのみでアクセスするCalDAV、CardDAV、IMAP、SMTP、POPベースのサードパーティ製アプリが含まれる
- ユーザーのGmail設定からIMAPの有効化/無効化設定も削除された
- この日以前からLSAを使っていたユーザーは、当初は2024年9月30日まで継続利用できる予定だった
- 2024年9月30日 からは、すべてのGoogle WorkspaceアカウントでLSAアクセスを無効化する予定だった
- CalDAV、CardDAV、IMAP、POP、Google Syncは、パスワードのみでログインする場合は動作しなくなる
- 引き続き利用するには、より安全なアクセス方式であるOAuthでログインする必要がある
- その後、日程は複数回調整された
- 2024年10月15日 の更新でロールアウトは年末まで一時停止され、2025年1月に再開予定へ変更された
- 2025年1月27日 の更新でロールアウトが再開され、最終的な無効化は2025年3月に予定された
- 2025年2月12日 の更新でLSAサポート終了日は2025年3月14日に変更された
- 2025年4月29日 の更新で、LSAは 2025年5月1日 からサポートされなくなった
Google Syncを使う組織の確認ポイント
- 今回の変更には Google Syncの終了 も含まれる
- 当初のGoogle Sync終了日程は次のとおりだった
- 2024年6月15日 から、新規ユーザーはGoogle Sync経由でGoogle Workspaceに接続できなくなった
- 2024年9月30日 から、既存のGoogle SyncユーザーもGoogle Workspaceに接続できなくなった
- 組織内でGoogle Syncを使っているかどうかはAdmin Consoleで確認できる
- パス: Devices > Mobile & Endpoints > Devices
- フィルタ: Type: Google Sync
管理者とMDM構成への影響
- 管理者は、エンドユーザーがGoogle Workspaceアカウントでアプリを使い続けるには OAuthベースのアクセス方式 に移行するよう案内する必要がある
- 影響を受けるユーザー情報は、今後数か月にわたり組織へメールで提供される予定である
- MDMプロバイダでIMAP、CalDAV、CardDAV、POP、Exchange ActiveSync(Google Sync)プロファイルを構成していた組織も影響を受ける
- 2024年6月15日から、パスワードベースのIMAP、CalDAV、CardDAV、SMTP、POP、Exchange ActiveSync(Google Sync)のMDMプッシュは、LSAへ初めて接続しようとする顧客には機能しなくなった
- Google Endpoint Managementを使っている場合、CalDAVおよびCardDAV向けの Custom Push Configuration 設定を有効にできない
- 2024年9月30日から、既存ユーザー向けのパスワードベースのIMAP、CalDAV、CardDAV、SMTP、POPプッシュは機能しなくなった
- 管理者はMDMプロバイダを使って Google Account をプッシュする必要があり、この方式ではiOSデバイスにGoogleアカウントをOAuthで再追加する
- パスワードベースのExchange ActiveSync(Google Sync)プッシュも既存ユーザーには機能しなくなった
- Google Endpoint Managementの“Custom push configuration-CalDAV”と“Customer push configuration-CardDAV”設定は効力を失う
デバイス・アプリ・開発者ごとの移行方法
- スキャナーや他のデバイスがSMTPまたはLSAでメールを送信している場合、次のいずれかが必要になる
- OAuthを使うよう設定する
- 代替手段を使う
- そのデバイス用の アプリ パスワード を設定する
- ユーザー名とパスワードだけでGoogleアカウントにアクセスするアプリは、移行対応が必要である
- 終了日までに対応しなければ、ユーザー名とパスワードの組み合わせが正しくないというエラーが表示され、ログインできなくなる
- メールアプリごとの対応
- Outlook 2016以前はMicrosoft 365、Outlook for Windows、Outlook for Macへ移行する必要があり、これらはOAuthアクセスをサポートする
- 代替として Google Workspace Sync for Microsoft Outlook を利用できる
- Thunderbirdや他のメールクライアントはGoogleアカウントを再追加し、IMAPをOAuthで構成する必要がある
- iOSまたはmacOSのMailアプリ、Outlook for Macでパスワードのみのログインを使用している場合は、アカウントを削除してから再追加し、“Sign in with Google”を選択する必要がある
- カレンダーと連絡先アプリもOAuth対応方式へ移行する必要がある
- パスワードベースのCalDAVカレンダーアプリはOAuth対応方式へ切り替える必要があり、GoogleはGoogle Calendarアプリを推奨している
- iOSまたはmacOSのカレンダーアプリでパスワードのみのログインを使用している場合は、アカウントを削除してから再追加し、“Sign in with Google”を選択する必要がある
- iOSまたはmacOSでCardDAVにより連絡先を同期し、パスワードのみのログインを使用している場合は、アカウントを削除してから再追加し、“Sign in with Google”を選択する必要がある
- 他のプラットフォームやアプリでCardDAVとパスワードのみを使っている場合は、OAuth対応方式へ移行する必要がある
- OAuthをサポートしないアプリは、OAuthを提供するアプリに切り替えるか、アプリ パスワード を作成してアクセスする必要がある
- 開発者は、Google Workspaceアカウントとの互換性を維持するため、アプリ接続方式を OAuth 2.0 に更新する必要がある
- Googleは OAuth 2.0でGoogle APIにアクセスするための開発者ガイド と モバイルおよびデスクトップアプリ向けOAuth 2.0ガイド を提供している
個人Googleアカウントと適用範囲
- 個人Googleアカウントの利用者については、Gmail設定のIMAP有効化/無効化トグルが削除される予定である
- 個人アカウントのIMAPアクセスはOAuth経由で常時有効になっており、現在の接続には影響しない
- 個人Googleアカウントの利用者は追加対応を行う必要はない
- この変更はすべての Google Workspace顧客 に適用される
1件のコメント
Hacker Newsの意見
この記事を読んで一瞬ヒヤッとした——Gmailと連携するスクリプトやツールがいくつもあるため
それでも大丈夫そう。アプリ パスワードは引き続き動作するようで、今回の変更はアカウントの通常のユーザー名/パスワードを使う安全性の低いアプリのサポート廃止に近い
GoogleがOAuth以外を本当にすべてなくしてしまったら、どれほど多くの自動化が死ぬのか考えるだけでぞっとする
OAuthの複雑さが嫌いで、このPerlモジュールのドキュメントがその構造を解きほぐしているやり方が気に入った。自分と同じようにうんざりしている人が書いたに違いないと思える: https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Aut...
似た問題を経験していて、あるWorkspaceではアプリ パスワードがブロックされていた。小さなPythonスクリプトでOAuthトークンを取得し、それをパスワードのように使えばよい: https://github.com/google/gmail-oauth2-tools/blob/master/pyt...
例は https://github.com/lefcha/imapfilter/issues/186 を参照
今はメインのGmailアカウントが、ほかの複数のGmailアカウントの認証情報でSMTP送信できるようにするため、LSAスイッチをオンにし続ける必要がある。なぜGmailが別のGmailアカウントから見るとLSAなのか理解できない
小文字16文字で、4文字ごとに空白で区切られており、数字も特殊文字もない
Keepassは空白を取り除くと、これを65ビットのエントロピーしかない弱いパスワードと評価する
これがどう改善なのか分からない
OAuthへ移行できないなら、私のプロキシを使えば、OAuth 2.0を直接サポートしていないIMAP/POP/SMTPクライアントでも「モダン」なメールプロバイダーと一緒に使える: https://github.com/simonrob/email-oauth2-proxy
クライアント側がOAuthをまったく知る必要はない
OAuthへ移行できないなら、アプリ パスワードを作成して、これまで通りIMAPパスワードとして使い続ければよい
IMAP、SMTP、POPはGoogleアカウントと生活全般にかなりのアクセス権を与えるにもかかわらず、2段階認証を行う方法がなく、ボット対策の検証も提供しないため
そのため認証情報の総当たり攻撃が非常に簡単になり、Google規模ではそうした攻撃で多くの人の生活が台無しになり得る
これは良い変更で、数年前に行われるべきだった。実際には、IMAP/POP/SMTPアクセスをデフォルトで無効にするという形で、ある程度はすでに行われており、ほとんどのユーザーはそれで保護されている。今回は残りのユーザー向けの措置である
Dovecotで好みの認証モジュールを選び、入力パスワードを
pwd+otp codeとして読み取るように変えればよい。ユーザーが2段階認証を有効にしていれば最後の6桁を読み取り、TOTPと比較する一致すれば、そのIPをx分間許可するか、望むポリシーを適用すればよい
意外なほどよく動く
そのアドレスはGmailではなく、IMAP/POPを引き続き許可しているところであればよい。万能薬ではないが、一部のユースケースでは受け入れ可能な回避策になり得る
これは、優れたネイティブメールアプリからユーザーを引き離し、Google 自社アプリへ誘導しようとするものだ。
gmail.app や、まもなく廃止される Google Sync なしでは、リアルタイムのメール通知を受け取れない。嫌だ。Workspace にお金を払っていても嫌だ。デスクトップでは Mimestream がまだ動いているが、それも近いうちに狙われそうだ。
JMAP は優れた標準プロトコルだが、メールプロバイダーとメールアプリの間にある鶏と卵の問題のせいで、採用率がとんでもなく低い。Gmail が JMAP をサポートすれば、実装者たちがあちこちで対応するよう促せる。JMAP は通知やその他の機能もサポートしている。
メール向け OAuth はメール認証関連の複数の RFC に含まれており、何年も前から存在していた。
Thunderbird や複数のモバイルアプリは OAuth を使って Gmail を問題なくサポートしている。より大きな問題は、多くのデスクトップアプリが約10年前から IMAP と SMTP の変更実装をやめてしまったように見える点だ。
もはやメンテナンスされていないメールアプリなら、Google がリンク先の記事で案内しているようにアプリ別パスワードを使えばよい。それらは引き続き動作する。なくなるのは、基本アカウントのハードコードされたユーザー名／パスワード方式だ。
Office 2016 ユーザーにとっては大きな頭痛の種になるだろう。9月30日は Outlook のサポート終了よりまだ9か月ほど前だからだ。ただし大半のユーザーにとっては、かなり簡単に修正できそうだ。
メールは非同期なので、メッセージが届いてから10分後に気づいても問題ないはずだ。待っているメールなら、どうせ届くまで更新を連打するだろう。
もっと急ぎならテキストメッセージを送ればいい。電話はしないでほしい。電話は嫌いだ。
「アプリ パスワードは、Google アカウントへのアクセス権を安全性の低いアプリやデバイスに与える16桁のパスワードで、2段階認証がオンになっているアカウントでのみ使用できます」という説明がある: https://support.google.com/mail/answer/185833
「安全性の低いアプリやデバイス」が、Google が以前から推奨できたはずのサーバー側メカニズムだけを使えば、OAuth 対応アプリとセキュリティ面でほぼ同等になるというのは面白くないか。技術的にはアプリの機能ですらないように見える。
もちろん、「安全なワークフローが使いにくいアプリ」と呼ぶと伝わりにくいので、単純化は正当化できると言えるかもしれない。より大きな問題は、Google がセキュリティ上の懸念を常に自分たちのアジェンダに有利な形で解釈しがちで、この一片も例外ではないという点だ。
今になって、OAuth をサポートするよう更新できないアプリにそれを義務化しているだけだ。
アプリ パスワードは機能的にはほぼ全許可か全拒否だが、OAuth では読み取り、変更、設定変更といった権限を構成できる。
Android で Google OAuth2 が最も腹立たしい点は、メールクライアントやカレンダーに Google アカウントでログインするには、スマートフォン全体がその Google アカウントに紐づけられなければならないことだ。
さらに、その Google アカウントがデバイスポリシー権限まで持つことになる。私にはまったく理屈に合わないと思える。
アプリ内 WebView で OAuth2 を使うことも、Android では Google が簡単に制限できるため、回避もしにくい。
残念ながら、信頼できるメールクライアントは多くない。かなりの数が認証情報をリモートサーバーに送ってしまう。
追記: k9 はすでに IMAP 用 OAuth をサポートしている。
https://docs.k9mail.app/en/6.400/accounts/incoming_imap/
文言は少し曖昧だが、アプリ専用パスワードは引き続き動作するように見える。
引用文では、SMTP や LSA でメールを送信するスキャナーやデバイスは、OAuth を使うよう設定するか、代替手段を使うか、デバイス用のアプリ パスワードを設定する必要があるとされている。
また、OAuth をサポートしないアプリは、OAuth を提供するアプリに変更するか、アプリ パスワードを作成してアクセスするようにとされている。
そこで昨日 Google Workspace Support に直接尋ねたところ、回答は「アプリケーション パスワードは IMAP、POP、すべての SMTP 構成をサポートします」だった。
2つ目の文は、引き続き OAuth 採用を推し進める内容だった。私もそうしたいが、繰り返されるセキュリティレビューの費用は私たちのような小規模 SaaS アプリには耐えられないので、幸いアプリ パスワードを使い続ける予定だ。
これは Workspace アカウントに関する内容で、一般の Gmail アカウントには数年前にすでに適用された変更です
まだ個人の Gmail アカウントを iPhone の Mail.app から Microsoft Exchange オプションでアクセスしており、Fetch に縛られずこの方式でプッシュ通知を受け取っています
動作する理由は、約10年前の終了日以前に個人アカウントで Google Sync に作成した接続がまだ維持され、「既得権」のように認められているためです
そのため動作させるには、iPhone の Exchange GUID を、新規ログイン停止前に Google Sync にログインしていた当時の携帯電話の GUID に修正すればよいです
幸い、iPhone のバックアップを作成し、バックアップ内の plist ファイルを修正してから復元すれば、この GUID 変更が可能です
今も iPhone 14 Pro で個人の Gmail アカウントについて Mail.app とプッシュ通知を使っています
発表文上、アプリ パスワードは当面維持されるものと理解しています。しかし Google がいつかアプリ パスワードまで廃止するなら、OAuth クライアントが自費で セキュリティ評価を受けなければならない仕組みのため、GMail でサードパーティクライアントを使うことは大きく制限されるでしょう
メールは、まだ広く使われている最後の「オープンなメッセージングプロトコル」の一つであり、クライアントを選べますが、そうした流れは悲しい展開になるでしょう
会社で Microsoft の OAuth 移行を扱っていますが、かなり厄介でした
問題の一部は、あまりにも不透明なことにあります。トークンを送ると、サーバーは追加説明なしに「だめ」とだけ返します
Client Credentials フローがなぜ機能しないのかを突き止めるのに数日を費やし、結局ヘルプフォーラムの奥深くで「そう、client credentials flow はまだサポートされていない」という答えを見つけました。現在は IMAP/POP ではサポートされていますが、記憶では SMTP ではまだではないようです。ただし SMTP ではまだ OAuth は必須ではありません
次は正しい スコープ(scope) を突き止めることでしたが、当時はドキュメント化があまりよくありませんでした。サーバーのエラーメッセージもまったく役に立ちません
Google のメールサーバーはもう少し良いのでしょうか？
残念ながら、サーバーには認証されていないクライアントに「役立つ」情報を与える余裕はありません