こんにちは。

「.NET CSOM を使ったプログラミングと認証 (Authentication)」で解説したように、SharePoint Add-ins (SharePoint アドイン, 旧 App for SharePoint) では、認証用の Token が使用されており、これが正しく取得できないと、SharePoint にアクセスできません。
そして、なんと、SharePoint Add-ins の開発 (Debug) の最中に、この Token (SPAppToken) が null になる現象が発生することがあります。たまに発生するという類のエラー (例外) ではなく、一度こうなってしまったプロジェクトは、何度コンパイルしなおしても、作り直しても、この現象から回避できません。
今回は、この原因と対処方法について解説します。

原因

この原因は、デバッグ実行の際に使用される IIS Express の https (SSL) の URL が、Azure Active Directory (Office 365) に登録されている Application Principal (Service Principal) の URL と重複している場合に発生します。要旨を記載します。

• Visual Studio は、Debug の際に、使用する Web アプリケーションの Applicatoin Principal として、Id や Url の情報などを Azure Active Directory に登録します。(Provider-hosted の場合は、以前解説したように、AppRegNew.aspx を使って事前登録できます。)
• この際、もちろん、同じ Id の Application Principal や、同じドメイン (domain) の Application Principal は登録できません。
  つまり、もし、プロジェクトで　https://localhost:44304 が使用されていると仮定し、既に同じドメイン (localhost:44304) の Application Principal が登録されている場合、Visual Studio はこの登録をおこなわず、代わりに http (Non-SSL) のドメインを登録します。
• この結果、登録は成功します。しかし、Add-ins が Debug 実行される際は https (SSL) でホストされるため、この Add-ins のドメインは localhost:44304 ですが、Azure Active Directory にはこのドメインの Application Principal は別の情報 (Client Id) で登録されているため、結果として null の token を Add-ins に渡します。(つまり、許可されていないと判断されます。)

通常は、Debug 時に登録された Application Principal は、ブラウザーを閉じると削除されます。しかし、Debug で中断した場合など、簡単な理由で、この Application Principal が残ってしまいます。

確認方法

まず、説明の必要はないと思いますが、Visual Studio のプロジェクトで使用している https (SSL) のドメインは、プロジェクトのプロパティ ウィンドウで確認できます。(下図)

また、Azure Active Directory に登録されている Application Principal の確認は、「Azure Active Directory とは (事前準備)」に記載した手順で、下記の通りコマンドを入力して確認できます。(一覧が表示されます。)

C:\Window\System32\Windows\PowerShell\v1.0\powershell.exe  -version 2.0PS> Import-Module MSOnlinePS> Import-Module MSOnlineExtendedPS> $cr=Get-CredentialPS> Connect-MsolService -credential $cr(rem -- id/password prompt appears. and please login !)PS> Get-MsolServicePrincipal -All(rem -- check your app principals !)

上記の 2 つの結果を見比べて、同じドメインの Service Principal が既に存在していないか確認してみてください。

対処方法

上記の動作 (解説) からお分かりの通り、対処方法は 2 つあります。

まず 1 つ目の対処方法が、Visual Studio 側の Debug で使用するサーバー (IIS Express 上の Web サイト) のドメインを変更する方法です。
「IIS Express で、あれこれ」でぼやいたように、プロジェクト (つまり、サイト) で使用するサーバー (ポート番号など) は、プロジェクト (つまり、サイト) の絶対パスをキーとして %userprofile%\Documents\IIS\Express\config\applicationhost.config に定義されています。そこで、メモ帳を管理者権限で実行して applicationhost.config を開き、該当の箇所のポート番号を変更します。(Windows Azure Active Directory に登録されている Application Principal のドメインと重複しないポート番号に変更します。) 再度、Visual Studio のプロジェクトを開きなおすと、変更されたポート番号がプロジェクトに反映されます。Debug 実行をおこなうと、問題なく動作するはずです。

補足 : ここでは詳細の手順を省略しますが、WebMatrix を使って、IIS Express に登録されているサイトを削除しても構いません。(ゴミは、どんどん消してもらって構いません。Visual Studio でプロジェクトを新規作成すると、再作成されます。)

もう一方の対処方法は、Azure Active Directory 側の重複している Application Principal のほうを削除する方法です。
下記の通り、コマンドを入力します。(下記の Guid は、上記の Get-MsolServicePrincipal コマンドの出力結果として表示される AppPrincipalId です。)

PS> Remove-MsolServicePrincipal -AppPrincipalId <Guid>

いずれにせよ、開発中に、ゴミは、まめに消しておくと良いでしょう。面倒なトラブルの原因となります。
なお、間違えて、既定で入っている Application Principal を消さないように注意しましょう。(Get-MsolServicePrincipal コマンドの出力結果に表示される DisplayName を確認して消してください。)

稀に発生するように思われるかもしれませんが、考えてみれば、頻繁に起こるはずです。(むしろ、よく今まで発生しなかったと感心しています。。。) 例えば、チーム開発の際や、PC (開発機) を変えた際なども要注意です。単純な理由で、IIS Express が作成するポートは重なります。
以前、SharePoint User Group にお邪魔した際にもお伝えさせていただきましたが、SharePoint 開発者の方にとって、今後、Azure Active Directory は必須の技術となるので抑えておいてください。

※ 変更履歴 :

2015/05/05  App for SharePoint (SharePoint 用アプリ) を SharePoint Add-ins (SharePoint アドイン) に名称変更