OAuthスコープとアプリケーションの役割と権限
現在、私のアプリケーションは、役割と権限に基づいてユーザーのアクセスを確認しています。たとえば、ユーザーが管理者である場合、そのユーザーにはすべての権限があります。
ただし、現在、WebアプリケーションおよびOAuth APIのシングルサインオンおよびトークンベースの認証用にREST 2.0およびOpenIdConnectを実装しています。
OAuth2.0とOpenid connectは、アクセス制御のスコープに大きく依存しています。 account.write account.read account.deleteなどのスコープは、権限「CanCreateAccount」「CanReadAccount」「CanDeleteAccounts」「CanAssignRolesToPermissions」と非常によく似ています。
両者の違いがわかりません。この分離により、アクセスREST APIの場合、アプリケーションはクライアントのスコープをチェックし、ユーザーのアクセス許可を個別にチェックする必要があります。これにより、コードが重複する可能性があります。
OAuth 2.0のスコープとアプリケーションのアクセス許可は同じだと思いますか？これが当てはまる場合は、個別のアプリケーションのアクセス許可を維持する代わりに、アプリケーション全体でスコープに固執する必要がありますか？
たとえば、現在、ユーザーはロールに割り当てられており、ロールには権限があります。パーミッションをスコープに置き換えると、クライアント/ユーザースコープ/パーミッションチェック機能を複製する必要がなくなります。
スコープをパーミッションに置き換えてみませんか。これは、OAuth 2.0仕様に固執したいためであり、スコープは仕様全体で使用されます。
ScopesはClient appごとであり、permissionsはuserごとです。言い換えると、1つのクライアントアプリが特定のAPIにアクセスするためのスコープを持つことができますが、このクライアントアプリのユーザーは、このAPIで（役割に基づいて）異なるアクセス許可を持ちます。アプリケーションはスコープをチェックしないでください。 IdentityServer（タグとして使用しているようですので、これを使用することをお勧めしますOAuthオーセンティケーター）は、必要なスコープを持たないクライアントを拒否します）アプリはユーザー権限のみを確認する必要があります。