私はマイクロサービス アーキテクチャを使用して新しいアプリケーション プラットフォームを構築していますが、使用するさまざまな種類の認証/承認について多くのことを読んできました。
私は OAuth2/OpenID Connect に落ち着いていますが、私の仮定が正しいことを確認するためです。
アプリケーションの認証/承認を処理するフローが正しいかどうかを知りたいです。次に、信頼できるアプリの場合、OAuth がユーザーに同意を求めるのを防ぐにはどうすればよいですか?
私はマイクロサービス アーキテクチャを使用して新しいアプリケーション プラットフォームを構築していますが、使用するさまざまな種類の認証/承認について多くのことを読んできました。
私は OAuth2/OpenID Connect に落ち着いていますが、私の仮定が正しいことを確認するためです。
アプリケーションの認証/承認を処理するフローが正しいかどうかを知りたいです。次に、信頼できるアプリの場合、OAuth がユーザーに同意を求めるのを防ぐにはどうすればよいですか?
プロトコル/標準に関しては、あなたが説明したようなシステムに OAuth 2.0 と OpenID Connect を使用することは正しい決定です。それらは積極的に使用されており、多くのライブラリとサードパーティ プロバイダーのサポートを備えており、現在のシステムが示す HTTP への過度の依存を考慮して設計されています。
各アプリケーションの正しいフローを選択するという点では、その決定は、アプリケーションがサードパーティまたは信頼できるアプリケーションとして認識されていることに影響されません。それは、アプリケーションの展開特性に関するものであり、アプリケーションがエンドユーザーまたはアプリケーション自体に代わってリソースにアクセスする必要があるかどうかにも関係します。
Auth0 を確認する - どの OAuth 2.0 フローを使用すればよいですか? この決定プロセスの良い例です。
サードパーティ アプリケーションと信頼できるアプリケーションの区別は、ID プロバイダー/承認サーバーの裁量に任されています。これは通常、アプリケーションが信頼されている場合にエンドユーザーに明示的に同意を求めないようにするためにサポートされています。このような場合、エンドユーザーの同意をスキップするようにアプリケーションにフラグを立てることは、誰かが一方的かつ管理的に、このアプリケーションに同意が与えられたと判断する管理手順と見なされ、エンドユーザーに同意を求める必要はありません。
実際に一部のアプリケーションで管理者の同意をサポートすることを決定した場合は、これらのアプリケーションの特性により、それらを機密クライアントにすることができない場合 (クライアント アプリケーション自体を認証するための安全なメカニズムをサポートする場合)、または他の方法で確実にすることができない場合に注意してください。悪意のあるアプリケーションは、ユーザーの同意手順をスキップするために、信頼できるアプリケーションの偽装を試みる可能性があります。