ユーザーが何ができるか、ユーザーが何ができないかを管理するために可能なすべてのオプションが失われています。 私はロールから始まった：[Authorize(Roles = Constants.Roles.ModeratorAndUp)]。 ModeratorAndUpは文字列"Moderators, Administrators"です。
しかし、私はより柔軟なアプローチが必要です。過去3時間の間、私はクレームと許可について読んでいます。私もこの興味深いブログpostを見つけました。ASP.NETコアのアクセス許可
私は、Universalテンプレートと共にAngularとASP.NET Coreを使用しています。認証のために私はOpenIddictを使用しています。 私は本をフォローしていた。
認可と認証にJWTトークンを使用します。 .NETコアでどのように権限を処理するべきかわかりませんが、100種類のロールがあり、完全に混乱しています。また、私は新しいユーザーを作成するときに、私は手動でそれをarround 20の役割を追加する必要があります。ロール/パーミッションを持つグループを作成し、このグループにユーザーを追加することができればいいですね。しかし、この設計がOpenIdDictとJWTトークン認可でどのように機能するのか分かりません。
誰かが私を正しい方向に向けることができますか？私は自分で研究します。
グループ権限/ロールを変更したときにユーザーロールを自動的に更新するシステムを構築する必要があるかどうかはわかりません。クレームと一緒に行くべきですか... [Authorize]属性を使用したいと思います。
ASP.NETコアでJWTトークンの認証/承認を行うにはどのような方法がベストプラクティスですか。
は '、あなたはそれ – Tseng
を解決する方法を知っているよ、クレームのグループとしての役割を考えてみて。しかしOpenIdictとJWTのトークンオーソリゼーションでこのデザインがどう機能するのか分かりません。 "OpenIddictでのクレームの使用は、クッキーミドルウェアでのクレームの使用とはまったく変わりはありません（認可スタックは、認証するクッキーとトークンの両方に同じ概念が適用されます）。また、@ssmithが提案しているように、特権/権限も持っています。トークンにクレームが多すぎると思う場合は、https://stackoverflow.com/questions/42496306/openidconnect-access-token-size-and-accessing-claims-server-sideを見逃してはいけません。 – Pinpoint