現在、私のアプリケーションは、役割と権限に基づいてユーザーのアクセスを確認しています。たとえば、ユーザーが管理者である場合、そのユーザーにはすべての権限があります。
ただし、現在、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オーセンティケーター)は、必要なスコープを持たないクライアントを拒否します)アプリはユーザー権限のみを確認する必要があります。