RESTful APIでのAPIキーとHTTP認証とOAuth

私は、維持しているアプリケーションの1つに対応するRESTful APIの構築に取り組んでいます。現在、より制御されたアクセスとセキュリティを必要とするさまざまなものを組み込むことを検討しています。APIをセキュリティで保護する方法を調査しているときに、どのフォームを使用するかについていくつかの異なる意見を見つけました。HTTP-Authが最適な方法であると言うリソースもあれば、APIキーを好むリソースもあれば、OAuthで誓う他のリソース（私がSOで見つけた質問を含む）もありました。

そしてもちろん、APIキーなどを好む人は、OAuthがユーザーの代わりにアクセス権を取得するアプリケーション向けに設計されていると言っています（私が理解しているように、Facebookアカウントを使用してFacebook以外のサイトにサインインするなど）。特にサインアップしたサイトのリソースに直接アクセスするユーザー（Twitterサーバーにアクセスする公式のTwitterクライアントなど）ではありません。ただし、OAuthの推奨事項は、最も基本的な認証ニーズにも当てはまるようです。

では、私の質問は-すべてがHTTPS経由で行われるとすると、3つの間の実際的な違いは何ですか？いつ他の人よりも考慮すべきですか？

それはあなたのニーズに依存します。必要ですか：

• アイデンティティ– APIリクエストをしていると主張するのは誰ですか？
• 認証–彼らは本当に彼らが彼らがそうであると彼らが言う人ですか？
• 承認–彼らは彼らがしようとしていることをすることを許可されていますか？

または3つすべて？

API呼び出しの量または数を追跡するために呼び出し元を識別する必要があるだけの場合は、単純なAPIキーを使用します。APIキーを発行したユーザーがそれを他のユーザーと共有すると、APIキーを呼び出すことができることにも注意してください。

ただし、承認も必要な場合は、APIの呼び出し元に基づいて特定のリソースへのアクセスのみを提供する必要があるため、oAuthを使用します。

ここに良い説明があります：http : //www.srimax.com/index.php/do-you-need-api-keys-api-identity-vs-authorization/

APIキーまたはトークンは、REST APIの公開されたリソースへのアクセスを許可するため、直接認証および承認メカニズムのカテゴリに分類されます。このような直接的なメカニズムは、委任ユースケースで使用できます。

RESTエンドポイントによって公開されているリソースまたはリソースのセットにアクセスするには、そのIDに従ってリクエスターの権限を確認する必要があります。ワークフローの最初のステップは、要求を認証することによってIDを検証することです。後続のステップは、アクセスのレベル（つまり、読み取り、書き込み、または読み取り/書き込み）を許可するために、定義された一連のルールに対してIDをチェックすることです。上記の手順が完了すると、一般的な追加の懸念事項は、許可された要求のレート、つまり、リクエスタが特定のリソースに対して実行できる1秒あたりの要求数です。

OAuth（Open Authorization）は、委任アクセスの標準プロトコルであり、多くの場合、主要なインターネット企業がパスワードを提供せずにアクセスを許可するために使用します。明らかなように、OAuthは、リソース所有者に代わってサーバーリソースへの安全な委任アクセスを提供することにより、認証と承認の上記の懸念を満たすプロトコルです。これは、サードパーティがリソース所有者に代わってサーバーが管理するリソースにアクセスできるようにするアクセストークンメカニズムに基づいています。たとえば、Johnが委任を承認すると、ServiceXはJohnに代わってJohn SmithのGoogleアカウントにアクセスしようとします。次に、ServiceXには、Googleアカウントの詳細にアクセスするための時間ベースのトークンが発行されます。

APIキーの概念は、上記のOAuthトークンとよく似ています。主な違いは、委任がないことです。ユーザーは、連続するプログラムによる対話のために、サービスプロバイダーにキーを直接要求します。APIキーのケースも時間ベースです。OAuthトークンとしてのキーは、タイムリースまたは有効期限の対象となります。追加の側面として、キーとトークンは、サービス契約によるレート制限の対象となる可能性があります。つまり、1秒あたりのリクエスト数は一定数にしか対応できません。

要約すると、実際には、従来の認証と承認のメカニズムとキー/トークンベースのバージョンの間に実際の違いはありません。ただし、パラダイムは少し異なります。クライアントとサーバー間のすべてのやり取りで資格情報を再利用し続ける代わりに、サポートキー/トークンが使用されます。これにより、やり取り全体がスムーズになり、安全性が高まります（多くの場合、JWT標準、キー、およびトークンは、作成を回避するためにサーバーによってデジタル署名されます。

• 直接認証および承認：従来の資格情報ベースのバージョンの変形としてのキーベースのプロトコル。
• Delegated Authentication and Authorization：OAuthベースのプロトコルのように、今度は認証情報ベースのバージョンのバリエーションとしてトークンを使用します（全体的な目標は、第三者にパスワードを開示することではありません）。

どちらのカテゴリも、関心のあるリソースを所有するサーバーとの最初のやり取りに、従来のID検証ワークフローを使用します。