OAuth2を使用してGmailまたはMicrosoft 365をNextcloudメールに接続する
Nextcloud MailでGmailまたはMicrosoft 365を使用してOAuth2を設定し、送受信を確認し、一般的な同意エラーやSMTPエラーを解決します。
OAuth2 を使用して Gmail または Microsoft 365 を Nextcloud Mail に接続するには、メールプロバイダで Web アプリケーションを登録し、Nextcloud Mail のリダイレクト URI をその登録情報にコピーして、クライアント ID とシークレットを Nextcloud のグループウェア管理設定に保存します。次に、Mail でメールボックスを接続し、プロバイダのサインインプロンプトを承認します。正常に動作する設定では、単に認証成功画面を表示するだけでなく、受信メッセージを読み込み、テストメッセージを送信する必要があります。
Nextcloud Mailは、メッセージの読み取りにIMAP、送信にSMTPを使用します。OAuth2はIDプロバイダーから許可を取得する仕組みであり、XOAUTH2はメールクライアントがこれらのメールサービスにアクセストークンを提示するために使用するメカニズムです。これは、Nextcloudへのログインをすべてのメールサーバーで共通のシングルサインオンにするものではありません。
Nextcloudの現在の管理ドキュメントでは、専用のGmail OAuthおよびMicrosoft Outlook XOAUTH2統合について説明しています。MicrosoftのサポートはMail 3.0.0で追加されました。メニューの文言はMailおよびNextcloudのリリースによって異なる場合があります。このチュートリアルは、 2026年10月に確認されたNextcloud 35 Mail管理マニュアルに基づいています。
重要な制限事項: OAuth2を受け入れるカスタムIMAPプロバイダーは、Nextcloud MailのGmail/Microsoft設定画面では自動的にサポートされません。汎用OAuth2プロバイダーに関するNextcloud Mailの機能リクエストには、この点について記載されています。別のプロバイダーを使用する場合は、無関係なGoogleまたはMicrosoftの認証情報を入力するのではなく、ご使用のMailのバージョンとサポートされている認証方法を確認してください。
https://mail.google.com/、Googleのユーザーデータおよび検証ポリシーの対象となる、広範囲にわたる制限付きスコープを使用します。管理者は、提案された使用がこれらの要件を満たすかどうかを判断する必要があります。Google は、OAuth2 ウェブアプリケーションの手順と、 Gmail の XOAUTH2 スコープおよびプロトコルに関するドキュメントで、ウェブサーバーの登録フローを説明しています。テスト構成は初期検証に役立ちますが、テスト環境のままにしておく外部 OAuth アプリケーションは、通常、Gmail メールへのアクセスを要求すると、7 日後に期限切れとなる更新トークンを受け取ります。Googleのトークン有効期限に関するガイダンスを参照してください。そのため、毎週繰り返される再認証は、IMAP パスワードの破損ではなく、公開状態の制限を示している可能性があります。
IMAP.AccessAsUser.All。SMTP.Sendこれらoffline_accessのプロトコルアクセス許可を、Microsoft Graph の Mail.Read/Mail.Send アクセス許可と混同しないでください。登録の詳細については、Microsoft のアプリ登録に関するドキュメントとExchange Online の IMAP/SMTP OAuth の手順を参照してください。Nextcloud の一般的な設定に関するドキュメントでは、テナントフィールドは空のままになっていますcommon。テナント固有の値またはサポート対象のユーザー範囲を狭く設定する場合は、管理者が関連するアカウントの種類とポリシーの変更を確認した場合にのみ使用してください。
Nextcloudメールアカウントフォームでは、OAuthが設定されたGoogleエンドポイントが認識されている場合は「Googleでサインイン」と表示され、Microsoftエンドポイントが認識されている場合は「Microsoftでサインイン」と表示されます。これらの条件付きラベルについては、Nextcloudメールアカウントフォームの実際のソースコードで確認できます。プロバイダ固有のボタンが表示されることは、Nextcloudが意図した統合を認識したことを示す便利な初期兆候ですが、認証やメールボックスへのアクセスが完了したことを証明するものではありません。
| 観測結果 | 次に確認すべき事項 |
|---|---|
Googleが報告するredirect_uri_mismatchか、Microsoftが返信URLを拒否します。 | プロバイダに登録されているWebリダイレクトと、Nextcloud Groupwareに表示される正確なURIを比較してください。必要に応じて、HTTPSオリジン、リバースプロキシURL、パス、末尾のスラッシュを修正してください。 |
| 同意画面が表示され、アクセスが拒否されます。 | Google OAuthのオーディエンス、テストユーザーリスト、制限付きスコープの検証、またはMicrosoftテナントの同意と条件付きアクセスに関するポリシーを確認してください。セットアップを完了するために組織のポリシーを迂回しないでください。 |
| プロバイダのポップアップにはアカウントが接続されていると表示されるが、メールは接続されないか、空のままだ。 | メールに戻り、アカウントを更新し、Nextcloud のログを調べて、ユーザーが接続済みアカウントを持っていることを確認してください。コールバック メッセージだけでは証拠として不十分です。2026年 7 月に報告された Nextcloud の問題では、影響を受けるバージョンでプロバイダーのエラーが成功画面に正確に反映されないことが説明されています。 |
| Microsoft 365では、メッセージは受信されるが送信に失敗する。 | メールボックスとテナントの認証済みSMTP設定およびメール転送承認を確認してください。Exchange Onlineは、OAuthの同意が成功したかどうかに関わらず、SMTP認証を無効にする場合があります。メールボックスレベルの例外を要求する前に、セキュリティへの影響を評価してください。 |
| 以前は正常に動作していた接続も、再度認証が必要になります。 | クライアントシークレットの有効期限、取り消されたユーザー同意、リフレッシュトークンのステータス、そしてGoogleの場合はOAuthアプリがまだテスト段階であるかどうかを確認してください。再接続する前に、プロバイダーとNextcloudの設定で有効期限切れのシークレットを更新してください。 |
Microsoft は、Exchange Online の SMTP 認証に関するドキュメントで、メールボックスごとのオーバーライドを含む SMTP 認証制御について説明しています。特定のメールボックスを機能させるためだけにメールのセキュリティを全体的に弱めることは避けてください。ポリシーでプロトコルが禁止されている場合は、承認済みのメール クライアントまたは組織がサポートするワークフローを使用してください。
受信トレイの同期がそれでも失敗する場合は、Nextcloud のドキュメントをocc mail:account:export参照してメール アカウント ID を確認し、occ mail:account:sync -vvv ACCOUNT_ID的を絞ったトラブルシューティングを行ってください。グループウェアのトラブルシューティング マニュアルには、アカウントごとの IMAP/SMTP デバッグ ログについても説明されており、ログには機密情報が含まれている可能性があると警告しています。必要な情報のみをキャプチャし、共有する前にトークンとアドレスを編集し、その後詳細なデバッグをオフにしてください。
プロバイダーの同意が完了し、メールが現在のメッセージを取得でき、送信メールが宛先に届き、接続が繰り返し認証プロンプトなしで使用可能な状態を維持できれば、セットアップは使用準備完了です。これらのチェックのいずれかが失敗した場合は、OAuthアプリケーション全体をすぐに再作成するのではなく、その特定の段階のトラブルシューティングを行ってください。
Nextcloud MailでGmailまたはMicrosoft 365を使用してOAuth2を設定し、送受信を確認し、一般的な同意エラーやSMTPエラーを解決します。
OCCを使用してNextcloudへのアクセスを復元し、データベース移行のステータスを確認し、アーカイブ、Docker、またはSnapのインストールに適したコマンドを選択します。
NextcloudをLDAPまたはActive Directoryに接続し、ユーザーおよびグループフィルタを使用してアクセスを制限し、展開前に安全な認証を検証してください。
サポートされている2要素認証プロバイダーを有効にし、アカウント復旧の準備を行った後、すべてのユーザーまたは選択したNextcloudグループに対して2要素認証を必須にします。
Collabora CODEで編集されたファイルは、ストレージ層を暗号化し、一時データを保護し、暗号化と復元を検証することで安全に保護されます。
ホストアーキテクチャを確認し、CODEタグがARM64を公開していることを確認し、強制的に設定されているAMD64設定を削除し、イメージエラーを権限の問題やメモリの問題から切り離してください。
Collabora OnlineとownCloud Infinite Scale間のWOPI接続を設定し、適切なサービスURLを構成して、ドキュメントの編集内容が保存されることを確認します。
Collabora Online CODEでドキュメントのエクスポートを防止するには、WOPIのDisableExport権限を設定し、ホストとエディタがその権限を適用していることを確認してください。
NginxのTLS終端、Collaboraのルート、およびWebSocketヘッダーを設定し、実際のドキュメントを開く前に公開エンドポイントをテストしてください。
10分間のCODE切断の原因をプロキシ、ロードバランサー、またはWebSocketパスまで追跡し、タイムアウトを修正してセッションが接続された状態を維持することを確認してください。