1. ホーム
  2. design-patterns

[解決済み】REST APIのログインパターン

2022-04-13 05:54:30

質問

REST apiを作成していますが、apigeeの提案に忠実に、動詞ではなく名詞を使い、apiのバージョンをurlに焼き付け、コレクションごとに2つのapiパス、GET POST PUT DELETEの使用などを行っています。

私はログインシステムに取り組んでいますが、ユーザーにログインするための適切なRESTの方法がわかりません。 私はこの時点でセキュリティに取り組んでいるわけではなく、ログインパターンやフローだけです。 (後でHMACを使用した2段階のoAuthを追加する予定です。)

可能なオプション

  • のようなものへのPOST https://api...com/v1/login.json
  • PUTは次のようなものです。 https://api...com/v1/users.json
  • 思いもよらないことが...。

ユーザーをログインさせるための適切なRESTスタイルは何ですか?

どのように解決するのですか?

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

<ブロッククオート

すべてのRESTインタラクションは ステートレス . つまり、各 リクエストには コネクタがその情報を理解するために必要なすべての情報を提供します。 リクエストに先行するどのようなリクエストにも依存しない。 .

この制限によって4つの機能が実現されますが、この場合、1番目と3番目が重要です。

  • 第1回 : それ コネクタがアプリケーションの状態を保持する必要性を排除します。 リクエストの間 物理リソースの消費を抑えることができます。 とスケーラビリティの向上が期待できます。
  • 3位 : 仲介者が閲覧し リクエストを単独で理解する , これは、サービスが動的に再配置される場合に必要な場合があります。

さて、ここでセキュリティの話に戻りましょう。すべてのリクエストはすべての必要な情報を含んでいなければなりませんし、承認/認証も例外ではありません。これを実現するにはどうしたらいいでしょうか?文字通り、すべてのリクエストに必要な情報を電信で送ります。

これを実現する方法の一例として、次のようなものがあります。 ハッシュ型メッセージ認証コード または エイチエムエーシー . 実際には、これは現在のメッセージのハッシュコードをすべてのリクエストに追加することを意味します。ハッシュコードの計算方法は 暗号ハッシュ関数 との組み合わせで 秘密暗号鍵 . 暗号化ハッシュ関数 はあらかじめ定義されているか コード・オン・デマンド RESTの発想(例えばJavaScript)。 秘密の暗号鍵 は、サーバーからクライアントにリソースとして提供され、クライアントはそれを使ってリクエストごとにハッシュコードを計算する必要があります。

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

実際の動作について

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

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