私は、REST API を保護する方法を Web で探していました。Amazonの非 SSL および非 OAuth の方法と、現在の最新の HTTPS + OAuth 2 の方法のどちらかを決定しています (私は何かが欠けています）。
OAuth 2 の流れがよくわかりません。公開鍵と秘密鍵を指定すると、これらの鍵はアプリケーションのみを認証します。アプリケーションのユーザーはどうですか? アプリケーションの各ユーザーを表すサブ公開/秘密鍵はありますか?
例えば、「アプリ」が外部開発アプリではなく「企業アプリ」そのものの場合はどうでしょうか。1 つの公開鍵と秘密鍵によって、何千ものユーザーがどのように区別されるのでしょうか?
これは一般に「マルチユーザー OAuth」と呼ばれるものですか?
Amazon のソリューションには詳しくありませんが、単純なリクエスト署名を使用しているようです。反対に、OAuth2 はより洗練されています。複数のシナリオをサポートしており、「認証コード付与」フローと「暗黙的付与」フローが最も一般的に使用されています。以下の説明は、両方のシナリオに適用されます。
OAuth2 では、サービスは実際にはユーザー資格情報について何も知らないため、ユーザーの「サブキー」などはありません。サービスが承認を要求すると、ユーザーのブラウザを OAuth 承認サーバーにリダイレクトします。内部でいくつかの魔法が発生します (これはクライアント アプリケーションのブラック ボックスです)。ユーザーは必要に応じて認証し、要求を承認するかどうかを決定します。その後、ブラウザは認証結果とともにクライアント アプリケーションにリダイレクトされます。したがって、クライアント アプリケーションがユーザー資格情報について何も知ることは不可能ですが、それはまったく必要ありません。代わりに、ユーザーの保護されたリソースへのアクセスを可能にするトークンのみを受け取ります。トークンは基本的に、特定の操作に対する 1 回限りの承認であり、それ以上のものではありません。