REST API ログインパターン 質問する

ロイ・T・フィールディングとリチャード・N・テイラー著『現代ウェブアーキテクチャの原則的な設計』つまり、すべての REST 用語の由来となった一連の作業には、クライアントとサーバーの相互作用の定義が含まれています。

すべてのRESTインタラクションはステートレスつまり、それぞれリクエストには、コネクタがリクエストを理解するために必要なすべての情報が含まれており、その前に行われたリクエストとは関係ありません。。

この制限は 4 つの機能を実現しますが、この特定のケースでは 1 番目と 3 番目が重要です。

• 1位： それコネクタがリクエスト間でアプリケーションの状態を保持する必要がなくなります。これにより、物理リソースの消費が削減され、スケーラビリティが向上します。
• 3位: 仲介者が閲覧し、リクエストを個別に理解するサービスが動的に再配置される場合に必要となる場合があります。

さて、セキュリティのケースに戻りましょう。すべてのリクエストには必要な情報がすべて含まれている必要があり、承認/認証も例外ではありません。これを実現するにはどうすればよいでしょうか。文字通り、すべてのリクエストで必要な情報をネットワーク経由で送信します。

これをアーカイブする方法の例の1つはハッシュベースのメッセージ認証コードまたはＨＭＡＣ実際には、これは現在のメッセージのハッシュコードをすべてのリクエストに追加することを意味します。ハッシュコードは次のように計算されます。暗号ハッシュ関数と組み合わせて秘密暗号鍵。暗号ハッシュ関数あらかじめ定義されているか、オンデマンドコードREST 概念 (JavaScript など)。秘密暗号鍵サーバーはリソースとしてクライアントに提供し、クライアントはそれを使用してリクエストごとにハッシュコードを計算します。

たくさんの例がありますＨＭＡＣ実装はいくつかありますが、次の 3 つに注目してください。

• Amazon Simple Storage Service (Amazon S3) の REST リクエストの認証
• 質問「RESTful WCF API で HMAC 認証を実装する方法」に対する Mauriceless の回答
• crypto-js: 標準的で安全な暗号化アルゴリズムの JavaScript 実装

実際にどのように機能するか

クライアントが秘密鍵を知っている場合、リソースを操作する準備は完了です。そうでない場合は、認証と秘密鍵の取得のために一時的にリダイレクトされ（ステータスコード307 Temporary Redirect）、その後元のリソースにリダイレクトされます。この場合、クライアントを認証するための URL を事前に知る必要はありません (つまり、どこかにハードコードしておく必要はありません)このスキーマは時間とともに調整することが可能です。

これが適切な解決策を見つけるのに役立つことを願っています。