75

間違っている場合は訂正してください。従来の Web アプリケーションでは、ブラウザーはサーバーへの要求にセッション情報を自動的に追加するため、サーバーは要求の送信者を認識できます。実際に追加されるのは正確には何ですか？

ただし、API ベースのアプリでは、この情報は自動的に送信されないため、API を開発するときに、認証されたユーザーからの要求かどうかを自分で確認する必要がありますか? これは通常どのように行われますか？

4

6 に答える 6

124

HTTPプロトコルは設計上ステートレスであり、各リクエストは個別に実行され、個別のコンテキストで実行されます。

セッション管理の背後にある考え方は、同じクライアントからの要求を同じコンテキストに置くことです。これは、サーバーによって識別子を発行してクライアントに送信することによって行われます。その後、クライアントはこの識別子を保存し、サーバーが識別できるように後続のリクエストで再送信します。

クッキー

典型的なブラウザサーバーの場合。ブラウザは、ドメインごとにCookieと呼ばれるキーと値のペアのリストを管理します。

  • Set-CookieCookieは、 HTTP応答ヘッダーを使用してサーバーで管理（作成/変更/削除）できます。
  • Cookieサーバーは、 HTTPリクエストヘッダーを解析することでCookieにアクセス（読み取り）できます。

Webを対象としたプログラミング言語/フレームワークは、より高いレベルでCookieを処理する機能を提供します。たとえば、PHPはCookieの書き込み/読み取りを提供しsetcookieます$_COOKIE。

セッション

セッションに戻る、典型的なブラウザ-サーバーの場合（再び）、サーバー側のセッション管理はクライアント側のクッキー管理を利用します。PHPのセッション管理はセッションIDCookieを設定し、それを使用して後続のリクエストを識別します。

WebアプリケーションAPI？

さて、あなたの質問に戻りましょう。APIの設計と文書化を担当するのはあなたであるため、実装はあなたの決定になります。あなたは基本的にしなければなりません

  1. Set-Cookie応答本文（XML / JSON認証応答）内で、HTTP応答ヘッダーを介してクライアントに識別子を指定します。
  2. 識別子/クライアントの関連付けを維持するメカニズムがあります。たとえば、識別子00112233445566778899aabbccddeeffをクライアント/ユーザー番号に関連付けるデータベーステーブル1337。
  3. クライアントに、後続のすべてのリクエストで（1.）に送信された識別子を再送信させます。これは、HTTPCookieリクエストヘッダーの?sid=00112233445566778899aabbccddeeffparam（*）に含まれます。
  4. （2.）のメカニズムを使用して、受信した識別子を検索し、有効な認証があるかどうかを確認し、要求された操作を実行する権限を与えてから、認証されたユーザーに代わって操作を続行します。

もちろん、既存のインフラストラクチャに基づいて構築することもできます。アプリでPHPのセッション管理（1./2。と4.の認証部分を処理する）を使用し、クライアント側の実装でCookie管理を行う必要があります（ 3.）の面倒を見てから、残りのアプリロジックをその上で実行します。

（*）各アプローチには短所と長所があります。たとえば、GETリクエストパラメータを使用すると実装が簡単になりますが、GETリクエストがログに記録されるため、セキュリティに影響する可能性があります。重要な（すべて？）アプリケーションにはhttpsを使用する必要があります。

于 2012-06-27T23:48:26.960 に答える
48

セッション管理はサーバーの責任です。セッションが作成されると、セッション トークンが生成され、クライアントに送信されます (そして Cookie に保存されます)。その後、クライアントとサーバー間の次のリクエストで、クライアントは (通常は) トークンを HTTP Cookie として送信します。すべてのセッション データはサーバーに保存され、クライアントはトークンのみを保存します。たとえば、PHP でセッションを開始するには、次のようにするだけです。

session_start();  // Will create a cookie named PHPSESSID with the session token

セッションが作成されたら、データを保存できます。たとえば、ユーザーをログに記録したままにするには、次のようにします。

// If username and password match, you can just save the user id on the session
$_SESSION['userID'] = 123;

ユーザーが認証されているかどうかを確認できるようになりました。

if ($_SESSION['userID'])
    echo 'user is authenticated';
else
    echo 'user isn't authenticated';

必要に応じて、認証されたユーザーに対してのみセッションを作成できます。

if (verifyAccountInformation($user,$pass)){ // Check user credentials
    // Will create a cookie named PHPSESSID with the session token
    session_start();
    $_SESSION['userID'] = 123;
}
于 2012-06-23T18:54:31.407 に答える
10

Web アプリケーションと API の両方で、認証ユーザーにはさまざまな方法があります。いくつかの標準がありますが、独自のカスタム承認/および認証を作成することもできます。承認と認証の違いを指摘したいと思います。まず、アプリケーションは、リクエストの送信元であるユーザー (または API クライアント) を認証する必要があります。ユーザーが認証されると、アプリケーションは、ユーザーの ID に基づいて、認証されたユーザーが特定のアプリケーション (承認) を実行する権限を持っているかどうかを判断する必要があります。ほとんどの従来の Web アプリケーションでは、セキュリティ モデルに細かい粒度がないため、ユーザーが認証されると、ほとんどの場合、特定のアクションを実行する権限も与えられます。ただし、この 2 つの概念 (認証と承認) は、2 つの異なる論理操作として扱う必要があります。

さらに、従来の Web アプリケーションでは、ユーザーが認証および承認された後 (ほとんどの場合、データベースでユーザー名とパスワードのペアを検索することによって)、承認と ID 情報がセッション ストレージに書き込まれます。上記の回答のほとんどが示唆しているように、セッションストレージはサーバー側である必要はありません。ほとんどの場合、クライアント側の Cookie に暗号化して保存することもできます。たとえば、PHP CodeIgniter フレームワークはデフォルトでこれを行います。クライアント側でセッションを保護するためのメカニズムは数多くありますが、セッション データを保存するこの方法は、サーバー側のセッション ストレージで検索される sessionId を保存するよりも安全性が低いとは思いません。また、セッションをクライアント側に保存することは、分散環境では非常に便利です。

さらに、単純なユーザーとパスワードのペアによる認証は、データベース内の一致するユーザー レコードを検索するカスタム コードを使用して行う必要はありません。たとえば、ベーシック認証プロトコルやダイジェスト認証があります。Windows プラットフォームのようなプロプライエタリ ソフトウェアでは、 ActiveDirectoryなど、ユーザー トラフを認証する方法もあります。

ユーザー名とパスワードのペアを提供することだけが認証方法ではありません。HTTPS プロトコルを使用している場合は、デジタル証明書を使用した認証を検討することもできます。

特定のユース ケースでは、SOAP をプロトコルとして使用する Web サービスを設計する場合、 SOAP プロトコル用のWS-Security拡張もあります。

これらすべてを踏まえて、次の質問への回答は、WebApi の承認/認証メカニズムの選択の決定手順に入ると言います。

1) 対象となる視聴者は何ですか?それは公開されていますか?それとも登録 (有料) メンバーのみですか?
2) 実行されているか、*NIX、または MS プラットフォームか
3) 予想されるユーザー数
4) API が処理する機密データの量 (認証メカニズムの強化と強化の比較)
5) 使用できる SSO サービスはありますか

.. などなど。

方程式には多くの変数があるため、これで問題が少し解決することを願っています。

于 2012-06-29T17:52:49.630 に答える
1

APIベースのAPPがクライアントの場合、APIには、サーバーの応答ストリームからCookieを取得/読み取り、保存するオプションが必要です。同じサーバー/URLのリクエストオブジェクトを準備する際のCookieの自動追加用。利用できない場合、セッションIDを取得できません。

于 2012-06-27T09:45:03.043 に答える
1

確かに、標準的な環境で物事が「自動」である理由は、ユーザーにとって物事をきれいに保つために、URL伝播よりもCookieが優先されるためです。とは言うものの、ブラウザ（クライアントソフトウェア）は、すべてのリクエストとともにセッションCookieの保存と送信を管理します。

APIの世界では、単純なシステムでは、多くの場合、すべてのリクエストとともに認証クレデンシャルが渡されます（少なくとも私の業務では）。クライアントの作成者は、通常（私の経験では）Cookieストレージの実装、およびすべての要求での送信、および一般的に最低限以上のものを実装することに消極的です...

HTTPベースのAPI、HTTPベーシック/ダイジェストなど、他にもたくさんの認証メカニズムがあります。もちろん、間違いがなければ、これらのために特別に設計されたユビキタスなo-authです。Cookieは維持されず、クレデンシャルはすべての交換の一部です（かなり確実です）。

考慮すべきもう1つのことは、APIのサーバー上のセッションで何をするかです。Webサイトのセッションは、現在のユーザーにストレージを提供し、通常、ページからページへのデータベースの負荷を軽減するために少量のデータを保存します。もちろん、APIのコンテキストでは、物事は多かれ少なかれステートレスであるため、これはそれほど必要ではありません。それは本当にサービスが何をしているかに依存します。

于 2012-06-28T18:35:43.427 に答える
1

リクエストごとに何らかのトークンを送信することをお勧めします。

サーバーとサービスに応じて、これらはGET/POST リクエストのJSESSIONIDパラメータか、Web サービス リクエストの SOAP over HTTP のSAMLのような成熟したものになります。

于 2012-06-29T11:54:27.467 に答える