私はREST APIを作成しています.apigeeの提案に厳密に従い、動詞ではなく名詞を使用し、URLに焼き付けられたAPIバージョン、コレクションごとに2つのAPIパス、GET POST PUT DELETEの使用などを使用しています.
ログイン システムに取り組んでいますが、ユーザーをログインさせるための適切な REST の方法がわかりません。この時点では、セキュリティについては取り組んでいません。ログインのパターンまたはフローだけです。(後で、HMAC などを使用した 2 段階の oAuth を追加する予定です)
可能なオプション
https://api...com/v1/login.json https://api...com/v1/users.jsonユーザーのログインに適切な REST スタイルは何ですか?
Roy T. Fielding と Richard N. Taylor による Principled Design of the Modern Web Architecture、つまり、すべての REST 用語の由来となった一連の作業には、クライアントとサーバーの相互作用の定義が含まれています。
すべての REST 対話はステートレスです。つまり、各リクエストには、コネクタがリクエストを理解するために必要なすべての情報が含まれており、その前にあったリクエストとは関係ありません。
この制限は 4 つの機能を実現します。この特定のケースでは、1 番目と 3 番目が重要です。
それでは、セキュリティ ケースに戻りましょう。すべてのリクエストには必要な情報がすべて含まれている必要があり、承認/認証も例外ではありません。これを達成する方法は？リクエストごとに必要なすべての情報を有線で文字通り送信します。
これをアーカイブする方法の例の 1 つは、ハッシュベースのメッセージ認証コードまたはHMACです。実際には、これは現在のメッセージのハッシュ コードをすべてのリクエストに追加することを意味します。秘密の暗号キーと組み合わせて、暗号ハッシュ関数によって計算されたハッシュ コード。暗号化ハッシュ関数は、事前定義されているか、コード オンデマンドREST 概念 (JavaScript など) の一部です。秘密の暗号化キー は、サーバーからクライアントにリソースとして提供される必要があり、クライアントはそれを使用してすべてのリクエストのハッシュ コードを計算します。
HMACの実装例はたくさんありますが、以下の3つに注目していただきたいです。
クライアントが秘密鍵を知っていれば、リソースを操作する準備ができています。それ以外の場合、彼は一時的にリダイレクトされ (ステータス コード 307 一時リダイレクト)、承認して秘密鍵を取得した後、元のリソースにリダイレクトされます。この場合、クライアントを認証するための URL を事前に知る (つまり、どこかにハードコーディングする) 必要はなく、このスキーマを時間とともに調整することができます。
これが適切な解決策を見つけるのに役立つことを願っています!
TL;DR各リクエストのログインは、API セキュリティを実装するために必要なコンポーネントではありません。認証は必要です。
セキュリティ全般について話さずに、ログインに関する質問に答えることは困難です。一部の認証方式では、従来のログインはありません。
REST はセキュリティ ルールを指示しませんが、実際の最も一般的な実装は、3 方向認証を使用した OAuth です (質問で述べたように)。少なくとも各 API リクエストでは、ログイン自体はありません。3 方向認証では、トークンを使用するだけです。
このスキームにより、ユーザーはいつでもアクセスを取り消すことができます。私が見た公開されているほぼすべての RESTful API は、これを実装するために OAuth を使用しています。
ログインに関して問題（および質問）を組み立てるべきではないと思いますが、一般的にAPIを保護することを考えてください。
一般的な REST API の認証の詳細については、次のリソースを参照してください。
REST哲学の大部分は、APIを設計するときにHTTPプロトコルの可能な限り多くの標準機能を活用することです。その哲学を認証に適用すると、クライアントとサーバーはAPIの標準HTTP認証機能を利用します。
ログイン画面は、人間のユーザーのユースケースに最適です。ログイン画面にアクセスし、ユーザー/パスワードを入力し、Cookieを設定すると、クライアントは今後のすべてのリクエストでそのCookieを提供します。Webブラウザーを使用している人間は、個々のHTTP要求ごとにユーザーIDとパスワードを提供することは期待できません。
ただし、REST APIの場合、各リクエストに人間のユーザーに影響を与えることなくクレデンシャルを含めることができるため、ログイン画面とセッションCookieは厳密には必要ありません。また、クライアントがいつでも協力しない場合は、401「許可されていない」応答を返すことができます。 RFC 2617は、HTTPでの認証サポートについて説明しています。
TLS（HTTPS）もオプションであり、相手の公開鍵を検証することにより、すべての要求でサーバーに対するクライアントの認証（およびその逆）を可能にします。さらに、これはボーナスのためにチャネルを保護します。もちろん、これを行うには、通信前のキーペア交換が必要です。（これは特にTLSでユーザーを識別/認証することに関するものです。TLS/ Diffie-Hellmanを使用してチャネルを保護することは、公開鍵でユーザーを識別しなくても、常に良い考えです。）
例：OAuthトークンが完全なログイン資格情報であるとします。クライアントがOAuthトークンを取得すると、リクエストごとに標準のHTTP認証でユーザーIDとして提供される可能性があります。サーバーは、最初の使用時にトークンを検証し、チェックの結果を、リクエストごとに更新される存続可能時間とともにキャッシュできます。認証が必要なリクエストは401、提供されない場合は返されます。