トークンベースの認証の意味を理解したい。インターネットを検索しましたが、理解できるものが見つかりませんでした。
8 に答える
ここでよく説明されていると思います-長い記事の重要な文だけを引用します:
トークンベースの認証システムの背後にある一般的な概念は単純です。ユーザー名とパスワードを使用せずに、特定のリソースをフェッチできるトークンを取得するために、ユーザーがユーザー名とパスワードを入力できるようにします。トークンが取得されると、ユーザーはそのトークン (特定のリソースへの一定期間のアクセスを提供する) をリモート サイトに提供できます。
つまり、認証に 1 レベルの間接性を追加します。保護されたリソースごとにユーザー名とパスワードを使用して認証する代わりに、ユーザーはその方法で (限られた期間のセッション内で) 1 回認証し、代わりに時間制限のあるトークンを取得します。 、セッション中のさらなる認証にそのトークンを使用します。
多くの利点があります。たとえば、ユーザーはトークンを取得したら、限られた時間と限られたリソースのセットで信頼しても構わないと思っている他の自動化されたシステムにトークンを渡すことができますが、そうするつもりはありません。ユーザー名とパスワードを信頼するため (つまり、アクセスを許可されているすべてのリソースを永久に、または少なくともパスワードを変更するまで)。
それでも不明な点がある場合は、質問を編集して、何が 100% 明確でないかを明確にしてください。さらにサポートできると確信しています。
トークンベースの認証は、リクエストごとにサーバーに送信される署名付きトークンに依存します。
トークンベースのアプローチを使用する利点は何ですか?
クロスドメイン / CORS: Cookie + CORS は、異なるドメイン間ではうまく機能しません。トークンベースのアプローチでは、HTTP ヘッダーを使用してユーザー情報を送信するため、任意のドメインの任意のサーバーに対して AJAX 呼び出しを行うことができます。
ステートレス (別名サーバー側のスケーラビリティ):セッション ストアを保持する必要はありません。トークンは、すべてのユーザー情報を伝達する自己完結型のエンティティです。状態の残りの部分は、クライアント側の Cookie またはローカル ストレージに存在します。
CDN:アプリのすべてのアセットを CDN (JavaScript、HTML、画像など) から提供できます。サーバー側は単なる API です。
デカップリング:特定の認証スキームに縛られることはありません。トークンはどこでも生成される可能性があるため、これらの呼び出しを認証する単一の方法でどこからでも API を呼び出すことができます。
モバイル対応:ネイティブ プラットフォーム (iOS、Android、Windows 8 など) での作業を開始する場合、トークンベースのアプローチを使用するとこれが大幅に簡素化されるため、Cookie は理想的ではありません。
CSRF: Cookie に依存していないため、クロスサイト リクエストから保護する必要はありません (たとえば、サイトを共有し、POST リクエストを生成し、既存の認証 Cookie が存在しないため再利用することはできません)。 )。
パフォーマンス:ここではハード パフォーマンス ベンチマークを提示していませんが、ネットワーク ラウンドトリップ (データベースでのセッションの検索など) は、HMACSHA256 を計算してトークンを検証し、その内容を解析するよりも時間がかかる可能性があります。
Atoken
は、Server X
作成できた可能性のあるデータであり、特定のユーザーを識別するのに十分なデータが含まれています。
ログイン情報を提示Server X
して、token
;を要求する場合があります。次に、を提示して、ユーザー固有のアクションを実行するようにtoken
依頼する場合があります。Server X
Token
は、暗号化の分野からのさまざまな技術のさまざまな組み合わせ、およびセキュリティ研究のより広い分野からの入力を使用して作成されます。自分のtoken
システムを作成することにした場合は、本当に賢くするのが最善です。
トークンはサーバーによって作成されたデータの一部であり、特定のユーザーとトークンの有効性を識別するための情報が含まれています。トークンには、ユーザーの情報と、ユーザー名とパスワードを直接渡す代わりに、認証をサポートするすべての方法でユーザーがサーバーに渡すことができる特別なトークンコードが含まれます。
トークンベースの認証は、サーバーが提供するセキュリティトークンを使用して、サーバー、ネットワーク、またはその他の安全なシステムにログインしようとするユーザーを認証するセキュリティ技術です。
ユーザーがセキュリティトークンを渡すことにより、自分が有効なユーザーであることをサーバーに証明できる場合、認証は成功します。このサービスはセキュリティトークンを検証し、ユーザーリクエストを処理します。
トークンはサービスによって検証された後、クライアントのセキュリティコンテキストを確立するために使用されます。これにより、サービスは、後続のユーザー要求に対して承認の決定または監査アクティビティを実行できます。
質問は古く、技術は進歩しました。現在の状態は次のとおりです。
JSON Web Token (JWT) は、Web アプリケーション環境で関係者間でクレームを渡すための JSON ベースのオープン スタンダード (RFC 7519) です。トークンはコンパクトで、URL セーフであり、特に Web ブラウザーのシングル サインオン (SSO) コンテキストで使用できるように設計されています。
データベースまたはその他の方法でユーザーに関連付けられているのは単なるハッシュです。そのトークンを使用して、アプリケーションのコンテンツに関連するユーザー アクセスを認証および承認できます。クライアント側でこのトークンを取得するには、ログインが必要です。初めてログインした後、セッションやセッション ID などの他のデータではなく、取得したトークンを保存する必要があります。ここでは、すべてがアプリケーションの他のリソースにアクセスするためのトークンであるためです。
トークンは、ユーザーの真正性を保証するために使用されます。
更新:現時点では、 JWT (Json Web Token) と呼ばれるより高度なトークン ベースのテクノロジがあります。この技術は、複数のシステムで同じトークンを使用するのに役立ちます。これをシングル サインオンと呼びます。
基本的に、JSON ベースのトークンには、ユーザーの詳細とトークンの有効期限の詳細に関する情報が含まれています。詳細に基づいてトークンが無効または期限切れになった場合、その情報を使用して、リクエストをさらに認証または拒否できます。
新しい Web サイトに登録すると、多くの場合、アカウントを有効にするための電子メールが送信されます。そのメールには通常、クリックするリンクが含まれています。そのリンクの一部にはトークンが含まれており、サーバーはこのトークンを認識し、アカウントに関連付けることができます。通常、トークンには有効期限が関連付けられているため、リンクをクリックしてアカウントを有効にするのに 1 時間しかない場合があります。顧客が電子メールをチェックするために使用しているデバイスまたはブラウザがわからないため、Cookie やセッション変数ではこれは不可能です。