SharePoint Online へ .NET CSOM で接続するとき、いまだに SharePointOnlineCredentials とユーザー名＋パスワード認証に頼っている現場は少なくありません。しかし Microsoft 365 全体で進む Basic / レガシー認証廃止の流れの中で、この方式は「いつ突然つながらなくなってもおかしくない」危険な選択肢になっています。本記事では、SharePointOnlineCredentials への影響と、Azure AD（Microsoft Entra ID）ベースのモダン認証への具体的な移行方法を、CSOM 開発者向けに詳しく解説します。
SharePoint Online における Basic / レガシー認証廃止の背景
Basic 認証と「レガシー認証」とは何か
まず用語を整理します。
- Basic 認証：HTTP ヘッダーの
Authorization: Basic ...にユーザー名＋パスワード（Base64）を毎回送る古い仕組み。 - Cookie ベース認証：一度だけサインイン情報を送信し、以後は FedAuth などのクッキーで認証状態を維持する方式。
- モダン認証：OAuth 2.0 / OpenID Connect を使い、
Bearerアクセストークンを送る方式（Azure AD / Microsoft Entra ID）。
Microsoft のドキュメントやセキュリティ ベンチマークでは、Basic 認証だけでなく ユーザー名＋パスワードに依存する従来方式全体 をまとめて「レガシー認証」と呼び、組織として無効化することを推奨しています。
Microsoft 365 全体で進むレガシー認証廃止の流れ
Exchange Online などでは 2022～2023 年にかけて、EWS / POP / IMAP / Remote PowerShell などの Basic 認証が段階的に無効化されました。 これに続いて、Microsoft 365 全体で「レガシー認証クライアントのブロック」がセキュリティ ベースラインとして推奨されており、その中には SharePoint Online にアクセスする古いクライアントも含まれます。
特に SharePoint Online では、テナント設定の「モダン認証を使用しないアプリをブロックする（LegacyAuthProtocolsEnabled）」を 無効（ブロック） にすることで、レガシー認証に依存するクライアントを一括で締め出すことができます。この設定を false にすると、SharePointOnlineCredentials を使用するアプリもアクセスできなくなることが Microsoft のドキュメントやツールの説明で明言されています。
SharePointOnlineCredentials の正体とオンライン環境での位置付け
SharePointOnlineCredentials は何をしているのか
SharePointOnlineCredentials クラスは、従来の .NET Framework 版 CSOM に含まれている認証用クラスで、一般には次のように使われてきました。
var password = new SecureString();
foreach (var c in "P@ssw0rd".ToCharArray())
{
password.AppendChar(c);
}
var creds = new SharePointOnlineCredentials(
"[email protected]", password);
using (var ctx = new ClientContext("https://tenant.sharepoint.com/sites/demo"))
{
ctx.Credentials = creds;
ctx.Load(ctx.Web, w => w.Title);
ctx.ExecuteQuery();
}
内部的には、ユーザー名＋パスワードを使って SharePoint Online の認証サービスにサインインし、成功すると FedAuth などのクッキーを取得して、以後の CSOM リクエストでそのクッキーを送信する「Cookie ベース認証」です。
HTTP レベルでは「Basic ヘッダー」を毎回送っているわけではありませんが、ユーザー名＋パスワードを直接扱うレガシー認証に分類されることに変わりはありません。実際、テナント設定でレガシー認証クライアントをブロックすると、このクラスを使ったログインはまとめてブロックされます。
.NET Framework 版と .NET Standard 版 CSOM の違い
SharePoint Online の CSOM には、現在大きく分けて次の 2 系統があります。
| 項目 | .NET Framework 版 CSOM | .NET Standard 版 CSOM |
|---|---|---|
| ターゲット | .NET Framework 4.5 以降 | .NET Framework 4.6.1+, .NET Core 2.0+, .NET 5/6/7/8 など |
| クロスプラットフォーム | 不可（Windows のみ） | 可（.NET Standard 対応 OS） |
| SharePointOnlineCredentials | 利用可能（レガシー認証） | 利用不可（クラス自体が存在しない） |
| 推奨認証方式 | モダン認証へ移行推奨 | OAuth 2.0 アクセストークン必須 |
| NuGet パッケージ | Microsoft.SharePointOnline.CSOM（16.1.20211.12000 以降で .NET Standard を含む） | |
Microsoft の公式ドキュメントでも、.NET Standard 版 CSOM では SharePointOnlineCredentials を含む「レガシーの Cookie ベース認証」はサポートされず、開発者が Azure AD アプリケーションを使って OAuth アクセストークンを取得し、CSOM にはトークンだけを渡す方式が推奨とされています。
また、Q&A でも「.NET Standard / .NET Core では SharePointOnlineCredentials クラスは存在しないため、OAuth によるトークンベース認証を使う必要がある」と明言されています。
問い：Basic 認証廃止は SharePointOnlineCredentials に影響するのか？
「Exchange の Basic 認証廃止」とは別物だが、結論は同じ
Microsoft Learn などでアナウンスされている「Basic 認証廃止」の多くは、Exchange Online のメール系プロトコル（EWS / POP / IMAP など）についての話であり、CSOM の認証を直接止めるスイッチではありません。
一方で、SharePoint Online では「モダン認証を使用しないアプリをブロックする」テナント設定や、セキュリティ ベンチマークに従った レガシー認証クライアントのブロック が進んでおり、ここで SharePointOnlineCredentials を使うアプリもまとめて対象になります。
Microsoft Q&A の議論を整理すると、次のように理解するのが実務的です。
- HTTP ヘッダーの
Basicそのものが止まる＝Exchange の話が中心。 - しかし SharePoint Online でも「レガシー認証クライアントのブロック」を有効にすると、
SharePointOnlineCredentialsによる Cookie 認証を含めて 全部まとめて締め出される。 - 新規テナントや高セキュリティ テナントでは、既にこの設定がブロック側になっていることも珍しくない。
つまり、厳密には「Exchange の Basic 認証廃止」というイベントと SharePointOnlineCredentials の寿命は別ですが、Microsoft 365 全体でレガシー認証が締め出されていく流れの中で、このクラスを使い続けるのはもはや現実的ではない、というのが実情です。
環境別：いつまで SharePointOnlineCredentials が動くのか
| シナリオ | 現在の状態 | 中長期リスク | 推奨対応 |
|---|---|---|---|
| 既存の .NET Framework コンソール／サービスから SharePoint Online へ接続 | テナントのレガシー認証が許可されていれば動く | セキュリティポリシー変更やテナント移行のタイミングで突然 401/403 になりやすい | 早期に Azure AD ベースのモダン認証へ移行 |
| .NET 6/7/8 などの新規アプリ | SharePointOnlineCredentials 自体が存在せずコンパイル不可 | レガシー認証に戻す選択肢はほぼない | 最初から OAuth アクセストークン方式で構築 |
| PowerShell + CSOM での運用スクリプト | 古いスクリプトは SharePointOnlineCredentials ベースが多数 | MFA 有効化済みユーザーやレガシー認証ブロック テナントでは既に動かないケースが多い | PnP PowerShell やモダン認証に対応した接続モジュールへ書き換え |
特に、MFA 有効化・条件付きアクセス適用済みのアカウント では、SharePointOnlineCredentials による認証はテナント設定に関係なく失敗しやすく、Microsoft 自身もモダン認証（OAuth）への移行を強く推奨しています。
問い：移行先としてどの認証方式を選ぶべきか？
答えは Azure AD（Microsoft Entra ID）ベースの「モダン認証」一択
結論から言えば、SharePoint Online に .NET からアクセスする場合の移行先は、Azure AD（Microsoft Entra ID）から取得した OAuth 2.0 アクセストークンを使う「モダン認証」 しか現実的な選択肢はありません。
.NET Standard 版 CSOM では、SharePointOnlineCredentials を使ったレガシー認証はサポートされず、開発者が Azure AD アプリケーションを通じてトークンを取得し、CSOM への呼び出し時に Authorization: Bearer <token> を付与する方式が必須とされています。
代表的なトークン取得フロー
SharePoint Online に対してモダン認証でアクセスする場合、よく使われるフローは次の 2 パターンです。
| シナリオ | 推奨フロー | 概要 | 主な利用例 |
|---|---|---|---|
| ユーザーが操作するツール（WinForms / WPF / CLI など） | Authorization Code / Device Code（MSAL の PublicClientApplication） | ユーザーがブラウザやデバイスコード画面で Azure AD にサインインし、デリゲート権限付きのアクセストークンを取得 | 運用担当者向け GUI ツール、オンプレ PC からの一時作業 |
| 夜間バッチ・Azure Functions・Windows サービスなどのバックグラウンド処理 | クライアント資格情報フロー（MSAL の ConfidentialClientApplication） | Azure AD アプリ登録の Client ID＋シークレット／証明書でアプリケーション権限のアクセストークンを取得 | サイトコレクションの一括プロビジョニング、ログ収集、外部システム連携 |
どちらのフローでも、最終的には「SharePoint Online をリソースとするアクセストークン」を取得し、CSOM の ClientContext にヘッダーとして渡します。トークン取得に Microsoft Authentication Library（MSAL）を使うのが現在の標準です。
モダン認証への移行ステップ（全体像）
ステップ 1：現状の棚卸し
まず、次のような観点で「どこで SharePointOnlineCredentials を使っているか」を棚卸しします。
- どのアプリ／スクリプト／サービスが SharePoint Online に接続しているか（Git リポジトリやサーバーを検索）。
SharePointOnlineCredentialsやNetworkCredentialを使っている箇所を洗い出す。- 接続先テナント・サイト・アカウント種別（専用サービスアカウントか、利用者本人か）。
- 実行環境（.NET Framework / .NET 6+ / PowerShell / Azure Functions など）。
この時点で「.NET Framework でしか動かない古いアプリ」「PowerShell でサービスアカウントの ID/PW をハードコードしているスクリプト」など、リスクが高い箇所が洗い出されます。
ステップ 2：Azure AD（Microsoft Entra ID）でアプリ登録
次に、SharePoint Online 用の Azure AD アプリケーションを登録します。大まかな流れは次の通りです。
- Azure ポータルで「アプリの登録」を作成（通常はシングルテナント）。
- リダイレクト URI を用途に応じて設定（デスクトップアプリなら
https://login.microsoftonline.com/common/oauth2/nativeclientなどを使用）。 - クライアントシークレットまたは証明書を作成（バックグラウンド処理の場合）。
- 「API のアクセス許可」で必要な SharePoint Online / Microsoft Graph 権限を追加。
CSOM をそのまま使う場合は、SharePoint API に対して以下のような権限を付与するケースが多くなります。
- アプリケーション権限：
Sites.SelectedまたはSites.FullControl.All - 委任された権限：
AllSites.FullControlなど
組織のセキュリティポリシーに応じて、アプリケーション権限を使うか、ユーザー委任権限のみで運用するかを決めます。
ステップ 3：MSAL / Azure.Identity でアクセストークンを取得
トークン取得部分はアプリから独立させ、「認証ヘルパー」としてクラス化しておくと保守性が高くなります。代表的なパターンは次の通りです。
| フロー | MSAL のクライアント種別 | トークン取得メソッド例 | 想定シナリオ |
|---|---|---|---|
| Authorization Code / Device Code | PublicClientApplicationBuilder | AcquireTokenInteractive, AcquireTokenWithDeviceCode | 対話型ツール・運用ツール |
| クライアント資格情報フロー | ConfidentialClientApplicationBuilder | AcquireTokenForClient | バッチ、API、Azure Functions、Windows サービス |
SharePoint Online をリソースとする場合、AcquireTokenForClient では "https://tenant.sharepoint.com/.default" のようなスコープを指定するのが一般的です（/.default はアプリ登録で定義した権限セットをまとめて要求する特別なスコープ）。
ステップ 4：CSOM へのトークン付与（ExecutingWebRequest）
アクセストークンが取得できたら、CSOM の ClientContext を作成し、ExecutingWebRequest イベントで Authorization ヘッダーを追加します。
public static ClientContext CreateContextWithAccessToken(
string siteUrl, string accessToken)
{
var ctx = new ClientContext(siteUrl)
{
AuthenticationMode = ClientAuthenticationMode.Anonymous
};
ctx.ExecutingWebRequest += (sender, args) =>
{
args.WebRequestExecutor.RequestHeaders["Authorization"] =
"Bearer " + accessToken;
};
return ctx;
}
このパターンは Microsoft のサンプルや、多くのブログ記事・Q&A でも紹介されている、.NET Standard / .NET Core 時代の標準的な書き方です。
ステップ 5：CSOM パッケージを最新化
モダン認証に移行する前提として、NuGet パッケージ Microsoft.SharePointOnline.CSOM を 16.1.20211.12000 以降 に更新しておく必要があります。このバージョンから .NET Standard 版の CSOM が同梱されており、.NET 6/7/8 といった新しいランタイムでも動作させやすくなっています。
コード例：SharePointOnlineCredentials からモダン認証への書き換え
従来コード（SharePointOnlineCredentials）
// 従来の .NET Framework コンソール アプリの典型例
var siteUrl = "https://tenant.sharepoint.com/sites/demo";
var password = new SecureString();
foreach (var c in "P@ssw0rd".ToCharArray())
{
password.AppendChar(c);
}
var creds = new SharePointOnlineCredentials(
"[email protected]", password);
using (var ctx = new ClientContext(siteUrl))
{
ctx.Credentials = creds;
ctx.Load(ctx.Web, w => w.Title);
ctx.ExecuteQuery();
Console.WriteLine(ctx.Web.Title);
}
一見シンプルですが、サービスアカウントの ID/PW をどこかに平文で保存せざるを得ず、MFA や条件付きアクセスを利用できないなど、セキュリティ／運用面の制約が多いコードです。
書き換え例（アプリのみ：クライアント資格情報フロー）
using Microsoft.Identity.Client;
using Microsoft.SharePoint.Client;
public async Task DemoAppOnlyAsync()
{
var siteUrl = "https://tenant.sharepoint.com/sites/demo";
var tenantId = "<tenant-id>";
var clientId = "<client-id>";
var clientSecret = "<client-secret>";
var app = ConfidentialClientApplicationBuilder
.Create(clientId)
.WithClientSecret(clientSecret)
.WithAuthority($"https://login.microsoftonline.com/{tenantId}")
.Build();
// SharePoint Online をリソースとするスコープ
var scopes = new[] { $"{siteUrl}/.default" };
var result = await app.AcquireTokenForClient(scopes).ExecuteAsync();
var accessToken = result.AccessToken;
using (var ctx = CreateContextWithAccessToken(siteUrl, accessToken))
{
ctx.Load(ctx.Web, w => w.Title);
await ctx.ExecuteQueryAsync();
Console.WriteLine(ctx.Web.Title);
}
}
このパターンでは、アプリケーションはユーザーのパスワードを一切扱わず、Azure AD に登録したアプリケーションの ID＋シークレット（または証明書）でトークンを取得します。トークンに付与される権限は Azure AD 側で厳密に制御できるため、セキュリティ面で大幅な改善が期待できます。
書き換え例（ユーザー委任：Device Code フロー）
using Microsoft.Identity.Client;
using Microsoft.SharePoint.Client;
public async Task DemoDeviceCodeAsync()
{
var siteUrl = "https://tenant.sharepoint.com/sites/demo";
var tenantId = "<tenant-id>";
var clientId = "<client-id>";
var app = PublicClientApplicationBuilder
.Create(clientId)
.WithAuthority($"https://login.microsoftonline.com/{tenantId}")
.WithRedirectUri("https://login.microsoftonline.com/common/oauth2/nativeclient")
.Build();
var scopes = new[] { $"{siteUrl}/.default" };
var result = await app.AcquireTokenWithDeviceCode(
scopes,
callback =>
{
Console.WriteLine(callback.Message);
return Task.CompletedTask;
}).ExecuteAsync();
var accessToken = result.AccessToken;
using (var ctx = CreateContextWithAccessToken(siteUrl, accessToken))
{
ctx.Load(ctx.Web, w => w.Title);
await ctx.ExecuteQueryAsync();
Console.WriteLine(ctx.Web.Title);
}
}
Device Code フローを使うと、コンソール アプリなどブラウザをホストしづらい環境でも、ユーザー自身が Azure AD にサインインしてトークンを取得できます。パスワードはアプリに渡らず、MFA や条件付きアクセスもそのまま利用できる点が大きなメリットです。
PnP Framework / PnP Core SDK を活用したモダン化
既存コードの規模が大きい場合、純粋な CSOM から一気にすべてを書き換えるのは現実的ではありません。その際は、Microsoft 365 PnP コミュニティが提供する PnP Framework / PnP Core SDK を併用するアプローチも有効です。
- PnP Framework：従来の CSOM の上に構築された拡張ライブラリ。プロビジョニングやサイトテンプレートなど高レベル API が充実。
- PnP Core SDK：Graph / REST をラップした、よりモダンな .NET SDK。LINQ ライクなクエリなど、クラウドネイティブな開発スタイルに最適。
これらのライブラリは、内部で OAuth ベースのモダン認証を前提としており、MSAL との連携やトークンのキャッシュ処理をある程度隠蔽してくれます。新規機能は PnP Core SDK、既存 CSOM コードの周辺だけ PnP Framework というように、段階的なモダン化も実現しやすくなります。
移行時にハマりやすいポイントと対策
1. 「Graph 用トークン」を CSOM に流用してしまう
Microsoft Graph 向けに発行されたアクセストークン（スコープが https://graph.microsoft.com/.default など）は、そのまま SharePoint CSOM には使えません。CSOM で SharePoint Online にアクセスする場合は、リソースを SharePoint にしたトークン（例：https://tenant.sharepoint.com/.default）を取得する必要があります。
2. 権限不足で 401 / 403 が発生する
トークンが取得できていても、Azure AD アプリの権限に必要な SharePoint API 権限が含まれていない場合、CSOM 側では 401 Unauthorized や 403 Forbidden が返ってきます。特に Sites.Selected を使う場合は、PowerShell などでサイト単位にアプリを明示的に許可する必要がある点に注意してください。
3. レガシー認証が無効化されたタイミングで突然止まる
テナント管理者が「レガシー認証クライアントのブロック」を有効化したり、セキュリティ ベンチマークを適用したりすると、それまで普通に動いていた SharePointOnlineCredentials ベースのアプリが突然 401/403 を返すようになります。CIS Microsoft 365 Foundations などのベンチマークでは、このブロックとともに SharePointOnlineCredentials を利用するアプリがアクセスできなくなることが明記されています。
この種の事故を防ぐためには、移行完了前にレガシー認証をブロックしない よう管理者と十分調整しつつ、移行テストが完了した段階で段階的にブロックを有効化する、という計画的な切り替えが重要です。
4. トークンキャッシュや更新を考慮していない
長時間動作するサービスでは、アクセストークンの有効期限（通常 1 時間程度）を過ぎると 401 が返るようになります。MSAL は内部にトークンキャッシュを持っており、同じクライアントで AcquireTokenForClient や AcquireTokenSilent を呼び出すことで自動的に更新してくれます。毎回ログイン処理をやり直すのではなく、MSAL のキャッシュを活かした設計にすることで、リトライを含めた安定した運用が可能です。
まとめ：SharePointOnlineCredentials からの卒業が急務
ここまでの内容を整理すると、次のようになります。
SharePointOnlineCredentialsは、ユーザー名＋パスワードを元にクッキーを取得して CSOM に渡す レガシー認証方式 であり、MFA や条件付きアクセスと相性が悪い。- .NET Standard 版 CSOM ではこのクラスは廃止され、開発者が OAuth アクセストークンを取得して
Authorization: Bearerヘッダーを付与する方式が必須になっている。 - テナント設定やセキュリティ ベンチマークで「レガシー認証クライアントのブロック」が有効化されると、
SharePointOnlineCredentialsに依存するアプリはまとめて締め出される。 - 移行先としては、Azure AD（Microsoft Entra ID）ベースのモダン認証（Authorization Code / Device Code / クライアント資格情報フロー）を利用し、CSOM にはアクセストークンのみを渡す設計が唯一の正攻法。
- 新規開発はもちろん、既存の .NET Framework アプリや PowerShell スクリプトも、早めにモダン認証に載せ替えておくことで、「ある日突然つながらなくなる」リスクを大きく減らせる。
SharePoint Online の CSOM コードを見直すとき、「SharePointOnlineCredentials が出てきたら要リファクタリング」と覚えておくと、将来の障害を未然に防ぎやすくなります。まずは小さなツールやバッチからでも構わないので、Azure AD アプリ登録と MSAL を組み合わせたモダン認証への移行を、今日から少しずつ進めていくことをおすすめします。
コメント