App Service には、ポチポチーしただけでコードを変更することなく認証ができてしまう Easy Auth という素晴らしい機能があります。
公式ドキュメントはこちら。
公式ドキュメントの内容は十分に充実してますが、作ったChris Gillum さんのパーソナルなブログにある Architecture of Azure App Service Authentication / Authorization を元に書かれている（と思う）ので、興味本位で意訳してみました。
2016年の記事なのでドキュメントのリンクを新しいものにしたり、あとはざっくり私が知りたいことを意訳したものです。
Architecture
Easy Auth はアプリケーションと同じサンドボックスの中で実行されるネイティブの IIS Module として実装されています。有効にすると、 IIS のワーカープロセスにディスパッチされたすべての HTTP リクエストは、アプリケーションのコードが実行される前に、最初にこのモジュールを最初に通過します。
（図はオリジナルのブログより参照）
上図のように、モジュール（easyauth.dll）はアプリケーションと同じサンドボックスで実行されますが、アプリケーションとは完全に分離されています。Azure のポータルで有効にすることで、モジュールがインジェクトされます。
SDK や特定の言語、コードの変更は必要ありません。環境変数を使って構成されています。環境変数は、Azure ポータル（または Azure REST API) で 設定できます。
Alternatives
認証を自身で作る方法は、お気に入りの認証のミドルウェアをアプリケーションのコードに直接含めることです。開発者は多くの制御をできるようになりますが、より多くの作業が必要になるし、（OAuth 2、OpenID Connect、Cookie、暗号化、HMAC、CSRF、リプレイ攻撃など）何をしているのかを理解する必要があります。セキュリティに関連することなら恐ろしいでしょう。現実では、これらのことを考えたくありません。プラットフォームが面倒をみてほしいものです。
別の手段は、アプリの前に認証プロキシを配置することです。
API Managemant や個別の Gateway を置く方法がありますが、このアプローチは多くの一般的なアプリでは理想的ではないと判断されました。
Platform Integration
認証のレイヤーをプラットフォームに直接組み込む最大の利点は、プラットフォームととてもよく統合できることです。これで最終的にさまざまな方法で利益をもたらします。いくつかの例を示します。
ID の統合: ASP.NET で実装してる場合、ClientPrincipal.CurrentPrincipal を使って認証されたユーザー ID や Claim にアクセスできます。Authorize 属性といった Web API の属性もネイティブに機能します。PHP のアプリでも利点があります。REMOTE_USER server variable を自動でセットするので、PHP アプリはユーザーの ID を取得できます。
Logging: Application Logging 機能を使っている場合、Easy Auth のトレースがアプリケーションのトレースに含まれます。予期しない認証エラーが発生しても、既存のアプリのログを見れば、その詳細を容易に見つけることができます。
Error Tracing: より高度なデバッグには、Failed request Tracing を有効にします。Easy Auth はアプリの In-process で実行される IIS モジュールなので、エラーになったリクエストで実行された内容を見ることができます。EasyAuthModule_32/64 という名前のモジュールへの参照をみるだけです。一方、認証ミドルウェアは、 IIS がアプリケーションコードと認証ミドルウェアを区別できないため、この利点がありません。
File System Storage: Easy Auth のトークンストアを有効にしている場合、OAuth のトークンはディスクに直接保存しています。個別のストレージアカウントのプロビジョニングや管理の必要はありません。トークンストアについては今後の投稿で詳しく説明します。
Configuration: Easy Auth の構成は全て WebApps のアプリケーション設定に表示されています。アプリはこれらの設定を容易に読むことができて便利です。 Kudu の Environment ページで確認できます。Easy Auth の設定は、
WEBSITE_AUTH_のプレフィックスがついています。これにより、アプリケーション設定を使用して有効にできる実験的な機能の公開が容易にできます。Updates: アプリの再デプロイをすることなく、アプリに最新の機能や改善を加えることができます。
他のメリットを見逃してるかもしれませんが、これらの利点が、App Service の中で認証を統合するアプローチを選んだ理由の基本的なアイデアです。
Performance
パフォーマンスについての Easy Auth のゴールは、この機能によるオーバーヘッドを感じないようにさせることと、他の代替のソリューションよりもよくすることです。この設計はゲートウェイのアーキテクチャーより優れています。それは、クライアントとアプリケーションの間に追加のネットワークのホップがないためです。Easy Auth のモジュールは、アプリケーションのホスト（w3wp.exe）の In-process で動作しています。
コード自体については、Easy Auth はほとんどマネージドのコードでして作られています。気づいていたかもしれませんが、この投稿の前半でこれがネイティブのモジュールだと説明しました。しかしながら、ネイティブのレイヤーは、IIS とコアモジュールの実装の間にある小さな Shim にすぎません。これが意味することは、ASP.NET および System.Web に依存することなく、.NET で IIS モジュールを設計できることです。これは、非常に重要です。従来のマネージドモジュール（または ASP.NET）だと、ASP.NET 以外のアプリケーション（PHP や Node.js など）をホストする場合に全くメリットのない比較的重たいパフォーマンスのペナルティを招いてしまいます。
