ControllerBase
クラスにはChallenge
メソッドがあり、ChallengeResult
クラスのオブジェクトを返します。 CookieAuthenticationOptions
クラスにはAutomaticChallenge
プロパティがあります。
ChallengeResult
は外部ログインと関係があると思います。しかし、実際にはどのように機能しますか? 「チャレンジ」という言葉はどこから来たのですか?これには何が入っているのですか。
ChallengeResult
はActionResult
であり、実行されると、指定された認証スキームのハンドラーにチャレンジします。または、何も指定されていない場合は、デフォルトのチャレンジスキームのハンドラー。 ChallengeResultのソースコード
たとえば、次のようにできます。
return Challenge(JwtBearerDefaults.AuthenticationScheme); //Can specify multiple schemes + parameters
これは、JWTベアラー認証ハンドラーに挑戦します。このハンドラの場合、応答ステータスコードを401に設定して、そのアクションを実行するには認証が必要であることを発信者に通知します。
AutomaticChallenge
(ASP.NET Core 1.xの場合)は、これがデフォルトのチャレンジハンドラであることを示す設定です。これは、認証スキームが特に指定されていない場合に呼び出されることを意味します。
2.xでは、デフォルトのチャレンジスキームまたは上位のデフォルトスキームを指定できるように変更されました。
services.AddAuthentication(o =>
{
o.DefaultScheme = JwtBearerDefaults.AuthenticationScheme; //Default for everything
// o.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme; //Default specifically for challenges
})
チャレンジとは、基本的には「このユーザーが誰なのかわからない、本人であることを確認してください」という言い方です。したがって、トリガーされた認証ハンドラが、たとえばFacebook認証ハンドラーは、Facebook認証ページへのリダイレクトを発行することにより、チャレンジに反応します。ローカルアカウント認証ハンドラーは、ローカルサインインページへのリダイレクトを発行する場合があります。
JWTベアラー認証の場合、ハンドラーは401ステータスコードで応答する以外は何もできず、呼び出し側に任せて適切に認証されます。
この動作は、Facebookの認証が使用する OAuthHandler (HandleChallengeAsync
)(およびMicrosoftおよびGoogleの認証)で確認できます。
通常、ユーザーが誰であるかわからない場合はチャレンジを返し、ユーザーが誰であるかがわかっている場合は禁止を返しますが、試行したアクションを実行することは許可されていません。