1

私はアクセストークンを検証するためにJwtBearerMiddlewareを使用するoauth2リソースサーバーを持っています。セキュリティー・スタンプが変更された場合、アクセス・トークンが無効になることは今は控えています。このミドルウェアはセキュリティスタンプ自体を検証していないようです。jwtBearerMiddlewareのセキュリティスタンプバリデーター

私は、SecurityStampValidatorクラスがクッキー認証の妥当性を検証しているにすぎないと判断しました。

jsonのWebトークンからセキュリティースタンプを検証する必要がありますか?


それを行うには私の現在の方法は、私はJwtBearerMiddlewareを登録する際OnTokenValidatedイベントのイベントハンドラを登録することです。このイベントハンドラーでは、セキュリティーの主張をデータベースに照会して、トークンのトークンと比較するだけです。セキュリティスタンプが同じでない場合は、nullにコンテキストのTicketSecurityTokenを設定し、認証が必要な場合は最終的に401 httpステータスコードをスローする次のミドルウェアにスキップします。

app.UseJwtBearerAuthentication(new JwtBearerOptions 
{ 
    ... 
    Events = new JwtBearerEvents 
    { 
     OnTokenValidated = async (ctx) => 
     { 
      var securityStampClaim = ctx.Ticket.Principal.Claims.FirstOrDefault(claim => claim.Type == "AspNet.Identity.SecurityStamp"); 
      var subjectClaim = ctx.Ticket.Principal.Claims.FirstOrDefault(claim => claim.Type == OpenIdConnectConstants.Claims.Subject); 

      if (securityStampClaim == null || subjectClaim == null) 
       return; 

      var user = await userStore.FindByIdAsync(subjectClaim.Value, ctx.HttpContext.RequestAborted); 
      if (user?.SecurityStamp == securityStampClaim.Value) 
       return; 

      ctx.SecurityToken = null; 
      ctx.Ticket = null; 
      ctx.SkipToNextMiddleware(); 
     } 
    } 
}); 

これはどのように行う必要がありますか?

答えて

1

これはどのように行う必要がありますか?

技術的には、はい(コードを簡略化するためにSignInManager.ValidateSecurityStampAsync(principal)を使用することもできます)。言っ

、あなたは強く、彼らがトークンまたはクッキーが無効として、彼らはまた、使用されていると考えるべきであるかどうかを決定するために使用するだけで、「不透明な」文字列ではないので、あなたのJWTトークンにセキュリティ・スタンプを格納回避検討すべきであるASP.NETコアアイデンティティによるエントロピーの唯一のソースとして2FAトークンを生成することができます.JWTにそのまま保存すると、悪意のある第三者のクライアントアプリケーションによって容易に抽出され、ログインしたユーザー。

これは既知の問題ですが、AFAIK、それを修正する計画はありません:https://github.com/aspnet/Identity/issues/626

アクセストークンにセキュリティスタンプを保存する場合は、OpenIddictのデフォルト(暗号化)形式を使用することを検討してください。これは、ASP.NETコアが暗号化された認証Cookieで使用したものとまったく同じです。

+0

なぜ、asp IDがクレームの原則にセキュリティスタンプを格納するのですか? スタンプを検証するたびにデータベースにアクセスするのは効率的ではありませんか? –

関連する問題