いくつかの用語や仕組みを把握し、それらがどのように関係し、あるいはどのように重なり合うのかを見つけようとしています。理論的なウェブアプリケーションとモバイルアプリケーションの認証が焦点です。**トークン・ベース認証とクッキー・ベース認証の正確な違いや、それらが交差するかどうか/どのように交差するかに焦点が当てられています。
http basic/digest や oauth/aws auth のような複雑なシステムには興味がありません。
私は、いくつかの主張があり、それが正しいかどうか試してみたいと思っています。
1.モバイルアプリケーションでは、セッションを使用しない認証トークンの使用のみが可能です。ブラウザコンテキストでは、クライアントサイドでトークンを持続させるためにクッキーが必要です。 2.認証情報(通常はユーザー名/pw)を、範囲と時間を限定できるトークンと交換します。しかしこれは、トークンとそれに関連するすべてのものが、サーバーによって永続化され、処理されなければならないことを意味します。 3.トークンはサーバーサイドで失効させることができます。Cookieにはそのようなオプションはなく、期限切れになります/なるべきです。 4.4.クッキーのみを使用することは、セッションIDがユーザーアカウントに関連し、何ら制限されないことを意味します。
私はあまり的外れでないことを望んでいるので、何かあれば助けてください!
1.セッションベース認証**では、サーバーがサーバーサイドですべての作業を行います。大まかに言うと、クライアントは自分のクレデンシャルで認証し、session_id
(クッキーに保存することができる)を受け取り、これを以降のすべての送信リクエストに添付します。つまり、これはクレデンシャルのセットに相当するため、quot;token" と考えることができます。しかし、この session_id
文字列には何もありません。これは単なる識別子であり、それ以外のことはすべてサーバーが行います。これはステートフルです。この識別子をユーザーアカウントに関連付けます(例えばメモリやデータベース内)。このセッションは、特定の操作や特定の期間に制限することができ、セキュリティ上の懸念がある場合は無効化することができます。さらに重要なことは、このセッションをすべてその場で変更することができることです。さらに、ウェブサイト上でのユーザーの行動をすべて記録することができます。デメリットとしては、スケーラビリティが悪いこと(特に複数のサーバーファームで使用する場合)、メモリを大量に使用することが挙げられます。
2.トークンベース認証**では、サーバーサイドにセッションが永続化されません(ステートレス)。最初の手順は同じです。認証情報はトークンと交換され、その後のリクエストに添付されます(クッキーに保存することも可能です)。しかし、メモリ使用量の削減、容易な拡張性、完全な柔軟性(トークンは他のクライアントと交換可能)を目的として、必要な情報をすべて含む文字列(トークン)が発行され、クライアントがサーバーにリクエストするたびにチェックされます。トークンの使用・作成にはいくつかの方法があります: 1.ハッシュメカニズム(例:HMAC-SHA1)を使用する。
token = user_id|expiry_date|HMAC(user_id|expiry_date, k)
ここで、`user_id`と`expiry_date`は平文で送られ、結果のハッシュが添付される(`k`はサーバのみが知っている)。
1.トークンを対称的に暗号化する(例:AES)。
token = AES(user_id|expiry_date, x)
ここで,`x`は暗号化/復号化キーを表す.
1.RSAなど非対称に暗号化する。
token = RSA(user_id|expiry_date, private key)
生産システムは、通常、この2つの典型的なタイプよりも複雑です。例えば、Amazonはそのウェブサイトで両方のメカニズムを使用しています。また、ハイブリッドは、2 で説明したようにトークンを発行し、ユーザー追跡や失効の可能性のためにユーザーセッションを関連付けるために使用することができ、古典的なトークンのクライアントの柔軟性を維持することもできます。また、OAuth 2.0 では、短命で特定のベアラトークンと、ベアラトークンを取得するための長命のリフレッシュトークンなどを使用します。
ソースはこちら
HTTPはステートレスであり、認証された状態を持つためには、ユーザーに関する情報を参照するために使用される何らかのトークンが必要である。 このセッションIDは通常、Cookieの値として送られるランダムなトークンの形をしています。 OAuth Access Token は、ユーザーと、そのユーザーがアクセスできるリソースの スコープ
を識別するために使用されます。 OAuthシングルサインオンを使用するアプリケーションでは、OAuthアクセストークンは通常、セッションIDと交換され、より多様なユーザーの状態を追跡することができます。
攻撃者の視点からすると、セッションIDやOAuth Access Tokenを乗っ取ることは、ユーザー名とパスワードと同じくらい良いことであり、時にはそれ以上に良いこともあります。 セッション ID は、ユーザアカウントを侵害から保護するセキュリティ特性を持たなければならない。
開発者の観点からは、車輪を再発明してはいけません。 プラットフォームが提供するセッションマネージャを使い、それがOWASP Session Management guidelinesに適合するように構成されていることを確認してください。