ASP.NET Identityとは何か
Visual Studio 2013（以降、VS2013）のリリース時、「One ASP.NET（＊1）」のもとにASP.NETにも数多くの新機能が追加されました。今回紹介する「ASP.NET Identity」もその一つで、これまでのものとは別に一から設計された新たな認証、資格管理システムです。
でも、どうして新しいものを作る必要があったのでしょうか。この疑問に答えるために、これまでのASP.NETでの認証、資格管理システムについて、順に振り返っていきましょう。
ASP.NETに含まれるWebフォーム、MVC、Web API、SignalRといったさまざまなフレームワークを、柔軟に組み合わせてWebアプリケーションを作成できるよう、ライブラリやテンプレートを見直そうというビジョンのことです。詳しくは次のblogエントリを参照してください。
ASP.NET誕生（ASP.NET 1.0～）
2002年にASP.NETが誕生したときはASP.NETの認証、資格管理システムには、フォーム認証をベースとしたAPIが用意されました。しかし、資格情報を入力する画面や、認証、承認処理の多くを自前で実装する必要がありました。また、ユーザーの資格情報を保管するには、独自にSQL Serverなどのデータベースやテキストファイル、XMLファイルを用意して管理する必要がありました（図1）。
ASP.NETメンバーシップ登場（ASP.NET 2.0～）
そこで、2005年にリリースされたASP.NET 2.0では、資格情報を入力し、認証、承認を行うための各種ログインコントロールに加え、資格情報データストアを自動生成し、そのアクセスを行うためのAPIを提供する「ASP.NETメンバーシップ」が登場しました（図2）。ログインコントロールとASP.NETメンバーシップを使うことで、ユーザーの作成、削除などの管理を行う専用ページ、および管理情報を保管するデータベース、さらに認証、資格情報の取得まで、ほとんどコードを書くことなく実現できるようになりました。
しかし、大きな力には代償が伴うものです。ASP.NETメンバーシップは確かに手軽なのですが、次のような問題がありました。
資格情報のデータベーススキーマはSQL Server限定
SQL Server以外のデータベースを使用するには、サードパーティ製の「メンバーシッププロバイダー」を使うか、自作する必要があります。
資格情報をカスタマイズすると、管理が大変になる
資格情報に「誕生日」といった独自の情報を追加することは可能です。しかし、基本となるユーザー名などの資格情報とは別のテーブルに追加されてしまうため、メンテナンスが難しくなってしまいます。
リレーショナルデータベースを前提としている
ASP.NETメンバーシップの各機能を提供する「メンバーシッププロバイダー」を自作すれば、SQL Server以外に資格情報を保管することはできます。しかし、あくまでその仕組みはリレーショナルデータベースを前提としています。そのため、キーバリューストア（KVS）のようないわゆる"NoSQL"を相手に実装すると、明示的に「未実装」としてNotSupportExceptionをスローするように実装しなければならないメンバーが大量にあり、直観的とはいえません。
ユニットテストが難しい
近年の開発では、ユニットテストを始めとしたコードによる自動化テストが当たり前となってきています。しかし、ASP.NETメンバーシップが生まれた時代はそうではありませんでした。そのため、ASP.NETメンバーシップはスタブ、モックなどを利用したユニットテストがしやすい構造にはなっていません。
ソーシャルログイン未対応
近年のSNSの隆盛により、Facebook、Google、Twitterといった外部のソーシャルアカウントを認証に使いたいというケースも増えています。しかし、ASP.NETメンバーシップでは、これを実現するのは容易ではありません。
