MVC 5のシングルページアプリテンプレートで新しいOWIN Bearer Token認証プロセスを理解しようとしています。間違っている場合は、OAuthパスワードクライアント認証フロー、Bearer Token認証は、Bearerアクセストークンコードのhttp承認リクエストヘッダーをチェックして、リクエストが認証されているかどうかを確認することで機能します。特定のリクエストが認証されているかどうかをCookieに依存しません。
この投稿によると:
public override async Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context)
{
using (IdentityManager identityManager = _identityManagerFactory.CreateStoreManager())
{
if (!await identityManager.Passwords.CheckPasswordAsync(context.UserName, context.Password))
{
context.SetError("invalid_grant", "The user name or password is incorrect.");
return;
}
string userId = await identityManager.Logins.GetUserIdForLocalLoginAsync(context.UserName);
IEnumerable<Claim> claims = await GetClaimsAsync(identityManager, userId);
ClaimsIdentity oAuthIdentity = CreateIdentity(identityManager, claims,
context.Options.AuthenticationType);
ClaimsIdentity cookiesIdentity = CreateIdentity(identityManager, claims,
_cookieOptions.AuthenticationType);
AuthenticationProperties properties = await CreatePropertiesAsync(identityManager, userId);
AuthenticationTicket ticket = new AuthenticationTicket(oAuthIdentity, properties);
context.Validated(ticket);
context.Request.Context.Authentication.SignIn(cookiesIdentity);
}
}
GrantReourceOwnerCredentials関数は、次の行でチケットを作成するだけではありません:context.Validated(ticket);ただし、Cookie IDを作成し、次の行でCookieに設定します。context.Request.Context.Authentication.SignIn(cookiesIdentity);
だから私の質問は、この関数のクッキーの正確な目的は何ですか? AuthenticationTicketは認証目的には十分ではありませんか?
SPAテンプレートには、Cookie認証とトークン認証の2つの認証メカニズムが実際に有効になっています。これにより、MVCとWeb APIコントローラーアクションの両方の認証が可能になりますが、追加のセットアップが必要です。
WebApiConfig.Registerメソッドを見ると、次のコード行が表示されます。
_ config.SuppressDefaultHostAuthentication();
_
これは、Web APIにCookie認証を無視するように指示します。これにより、 質問に投稿したリンク で説明されている問題のホストを回避できます。
「... SPAテンプレートは、MVC認証などの他のシナリオを有効にするために、アプリケーションCookieミドルウェアをアクティブモードとして有効にします。したがって、リクエストにセッションCookieがあるがベアラートークンがない場合、Web APIは引き続き認証されます。 APIのCSRF攻撃に敬意を表してほしい。別のマイナスの影響は、リクエストが不正な場合、両方のミドルウェアコンポーネントがチャレンジを適用することです。Cookieミドルウェアは、302への401応答を変更してログインページにリダイレクトしますこれは、Web APIリクエストで必要なものでもありません。」
そのため、承認が必要なconfig.SuppressDefaultHostAuthentication()
Web API呼び出しでは、リクエストとともに自動的に送信されるCookieを無視し、「Bearer」で始まるAuthorizationヘッダーを探します。 MVCコントローラーはCookie認証を引き続き使用しますが、トークン認証メカニズムはWebページ認証にそぐわないため、トークン認証メカニズムについては無知です。
Cookieの存在も困惑しました。これは、ベアラートークン認証シナリオでは明らかに必要ではないからです... this postで、作成者は個々のアカウントテンプレートを分析し、クッキー:
このメソッドは、アプリケーションCookieも設定します。その理由はわかりません。
私の推測では、テンプレートの作成者はさまざまな種類の認証ロジックの例を示したいと考えていましたが、この特定のケースでは、認証情報をベアラートークン認証JSONペイロードと標準認証クッキー。
JSON認証ペイロードが、暗号化されたチケットに加えて、追加の(不要な)暗号化されていないプロパティ(ユーザーID)も含むように設定されているという事実は、この理論をサポートしているようです:
var properties = CreateProperties(user.UserName);
var ticket = new AuthenticationTicket(oAuthIdentity, properties);
テンプレートの作成者は、ベアラトークン認証を実現するために最低限必要なものではなく、いくつかの有用な例を提供したかったようです。これは、上記のリンクされた投稿でも言及されています。
Cookieには1つの重要な目的があります。その値には、ページ上のクライアント側のJavaScriptによって抽出できるベアラートークンが含まれています。つまり、ユーザーがF5キーを押すかページを更新すると、Cookieは通常持続します。クライアント側のjavascriptは、ページのリロード時にCookieからベアラートークンを取得できます。