REST APIログインパターン

181

私はREST APIを作成しています。動詞ではなく名詞を使用し、URLに焼き付けられたAPIバージョン、コレクションごとに2つのAPIパス、GET POST PUT DELETEの使用法などを使用して、apigeeの提案に厳密に従っています。

ログインシステムに取り組んでいますが、ユーザーにログインするための適切なREST方法がわかりません。この時点ではセキュリティに取り組んでいません。ログインパターンまたはログインフローのみです。（後で、HMACなどを使用して2ステップのoAuthを追加します）

可能なオプション

のようなものへのPOST https://api...com/v1/login.json
のようなものへのPUT https://api...com/v1/users.json
私が持っていない何か...

ユーザーのログインに適切なRESTスタイルは何ですか？

api rest design-patterns

— スコットルーナック
ソース

それが応答フォーマットです。.jsonはサーバーにjsonで応答するように指示し、.xmlはサーバーにxml形式で応答するよう指示します。代わりに、それを？の後ろにあるオプションのパラメーターにします。 blog.apigee.com/detail/...

— スコットRoepnack

ヘッダーでのみ、URLで行われたコンテンツネゴシエーションを見たことがない。URLでは、キャッシュなどのメリットが失われます。

— 2012

@ScottRoepnackでは、AcceptHTTPヘッダーを検討する必要があります。

— Alessandro Vendruscolo

@Oded Acceptヘッダーを使用した場合はもあるVary: Acceptので、キャッシングは影響を受けません。拡張のConnegは以前に議論されました。でも、そこにションジラの答えがあると思う。

— cmbuckley

@Oded-わかりません。URLでコンテンツタイプを（クエリパスの.jsonサフィックスとして、またはtype = jsonクエリパラメータとして）指定すると、キャッシュの利点が失われるのはなぜですか？そして、この場合「あなた」は誰ですか？キャッシュのメリットを失う人は誰ですか？クエリのパスやパラメータの内容に関係なく、クエリの結果をキャッシュできるように思えます。

— Cheeso 2013年

回答:

138

Roy T. FieldingおよびRichard N. TaylorによるPrincipled Design of the Modern Web Architecture、つまりすべてのREST用語に由来する一連の作業には、クライアントとサーバーの相互作用の定義が含まれています。

RESTの対話はすべてステートレスです。つまり、各リクエストには、先行するリクエストとは関係なく、コネクタがリクエストを理解するために必要なすべての情報が含まれています。

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

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

では、セキュリティケースに戻りましょう。すべてのリクエストには必要な情報がすべて含まれている必要があり、承認/認証も例外ではありません。これを達成する方法は？文字通り、すべての要求でワイヤーを介して必要なすべての情報を送信します。

これをアーカイブする方法の例の1つは、ハッシュベースのメッセージ認証コードまたはHMACです。実際には、これは現在のメッセージのハッシュコードをすべてのリクエストに追加することを意味します。暗号化ハッシュ関数と秘密の暗号化キーを組み合わせて計算されたハッシュコード。暗号化ハッシュ関数は事前定義されているか、コードオンデマンド RESTの概念（JavaScriptなど）の一部です。秘密暗号鍵 はリソースとしてサーバーからクライアントに提供される必要があり、クライアントはそれを使用してすべての要求のハッシュコードを計算します。

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

実際の仕組み

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

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

— アキム
ソース

MACはメッセージの信頼性を証明し、改ざんから保護することを目的としています

— yrk

例の1つ、事前に「ログインURL」を知らなくてもユーザー/クライアント認証を処理する方法を追加

— Akim

：ここではRESTサービス用のステートレス認証の例と他の2件の素敵な記事ですblog.jdriven.com/2014/10/... technicalrex.com/2015/02/20/...

— ウラジミールRozhkov

各リクエストのTL; DRログインは、APIセキュリティの実装に必須のコンポーネントではなく、認証です。

セキュリティ全般について話さずにログインに関する質問に答えることは困難です。一部の認証スキームでは、従来のログインはありません。

RESTはセキュリティルールを規定していませんが、実際の最も一般的な実装は、3ウェイ認証を使用したOAuthです（質問で述べたように）。少なくとも各APIリクエストでは、それ自体はログインしていません。3ウェイ認証では、トークンを使用するだけです。

ユーザーはAPIクライアントを承認し、長期間有効なトークンの形式でリクエストを行う権限を付与します
APIクライアントは、長命のトークンを使用して短命のトークンを取得します。
APIクライアントは、リクエストごとに有効期間の短いトークンを送信します。

このスキームにより、ユーザーはいつでもアクセスを取り消すことができます。私が見た実際に公開されているすべてのRESTful APIは、OAuthを使用してこれを実装しています。

ログインに関して問題（および質問）を組み立てる必要があるとは思わないが、APIの一般的な保護について考えてください。

REST APIの認証全般に関する詳細については、次のリソースをご覧ください。

— スラヴォ
ソース

はい、OAuth！非常に簡単な答え、受け入れられた答えでなければなりません、imho。

— 2018年

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、提供されないと返されます。

— wberry
ソース

「各リクエストは人間のユーザーに影響を与えることなく資格情報を含めることができるため」引用符に含まれるものが悪いため、3ウェイ認証とOAuthが発明されました。サーバーで資格情報を取り消すメカニズムなしで資格情報を提供する場合、SSLなしで使用すると安全ではなくなります。

— スラボ

ユーザーの概念があるときはいつでも、クライアントからサーバーに何かを渡して、どのユーザーを識別する必要があります。OAuthトークンは、実際のユーザーとパスワードの組み合わせではなく、確かに「資格情報」として機能します。TLSを使用してチャネルを保護することは、常に良いことですが、それはほとんど問題ではありません。Cookieを使用する場合でも、認証ヘッダーではなくCookieヘッダーを使用するだけで、リクエストごとに何らかのトークンがサーバーに送信されます。

— wberry

また、何らかの理由でTLSまたはOAuthを使用していない場合、ユーザー/パスワードを毎回送信するのは、1回だけ送信するよりも本当に悪いのでしょうか。攻撃者がユーザー/パスワードを取得できる場合、攻撃者はセッションCookieも取得できる可能性があります。

— wberry

Cookieと認証ヘッダーである認証ヘッダーの違いは、Cookieは常に特定のドメインに関連付けられることです。これは、APIがCookieを受信すると、それがどこから来たのかを知っていることを意味します（以前に同じドメインによって書き込まれたものです）。ヘッダーを使用すると、あなたは決して知りません、そしてあなたはこれのために特定のチェックを実装しなければなりません。一般的に私は同意します。どちらも資格情報ですが、資格情報を渡すことはログインではないと思います。ログインは、ドアを開くアクティブなアクションです。3ウェイ認証の場合、クライアントの最初の承認のみがログインになります。

— スラボ