トークンベースの認証の意味を知りたい。インターネットを検索しましたが、理解できるものが見つかりませんでした。
回答:
私はそれはここで十分に説明されていると思います -長い記事の重要な文章だけを引用します：
トークンベースの認証システムの背後にある一般的な概念は単純です。ユーザーがユーザー名とパスワードを使用せずに特定のリソースを取得できるトークンを取得するために、ユーザーがユーザー名とパスワードを入力できるようにします。トークンが取得されると、ユーザーはトークンを提供できます。これは、特定のリソースへの一定期間のアクセスを提供します-リモートサイトに提供します。
言い換えると、認証に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を計算してトークンを検証し、その内容を解析するよりも時間がかかる可能性があります。
A tokenはServer X作成された可能性のあるデータであり、特定のユーザーを識別するのに十分なデータが含まれています。
ログイン情報を提示Server Xしてtoken、そして、あなたはあなたにあなたtokenを提示Server Xし、いくつかのユーザー固有のアクションを実行するように頼むかもしれません。
Tokensは、暗号化の分野からのさまざまな手法のさまざまな組み合わせを使用して作成されるほか、より幅広いセキュリティ研究の分野からの入力を使用して作成されます。あなたが行って独自のtokenシステムを作成することを決定した場合、あなたは本当に賢いのが一番でした。
トークンはサーバーによって作成されたデータの一部であり、特定のユーザーとトークンの有効性を識別するための情報が含まれています。トークンには、ユーザー情報と、ユーザー名とパスワードを直接渡す代わりに、認証をサポートするすべての方法でサーバーに渡すことができる特別なトークンコードが含まれます。
トークンベースの認証は、サーバーが提供するセキュリティトークンを使用して、サーバー、ネットワーク、またはその他の安全なシステムにログインしようとするユーザーを認証するセキュリティ技術です。
ユーザーがセキュリティトークンを渡すことにより、サーバーに対して有効なユーザーであることを証明できる場合、認証は成功です。サービスはセキュリティトークンを検証し、ユーザー要求を処理します。
トークンはサービスによって検証された後、クライアントのセキュリティコンテキストを確立するために使用されます。これにより、サービスは、承認の決定を行ったり、連続するユーザー要求のアクティビティを監査したりできます。
トークンベース（セキュリティ/認証）
つまり、アクセスしたことを証明するには、まずトークンを受け取る必要があります。実際のシナリオでは、トークンは建物へのアクセスカードである可能性があり、それはあなたの家の鍵の鍵となる可能性があります。オフィスの鍵カードまたは自宅の鍵を取得するには、まず本人であること、および実際にそのトークンにアクセスできることを証明する必要があります。それは、誰かにあなたのIDを見せたり、秘密のパスワードを与えたりするような単純なものかもしれません。それで、オフィスにアクセスする必要があると想像してください。私はセキュリティオフィスに行き、IDを提示すると、このトークンが渡され、建物に入ることができます。これで、トークンを所持している限り、建物内でやりたいことを無制限に行うことができます。
トークンベースのセキュリティの利点は何ですか？
安全でないAPIを思い返すと、その場合に実行しなければならないことは、実行したいすべてのことに対してパスワードを提供しなければならないことでした。
想像してみてオフィスのドアに入るたびに、ドアの隣に座っている全員にパスワードを提供する必要があります。これはかなり悪いことです。つまり、オフィス内の誰もがパスワードを盗んで私たちになりすますことができるということです。それはかなり悪いことです。代わりに、もちろんパスワードとともにトークンを取得しますが、1人から取得します。そして、建物内のどこにでもこのトークンを使用できます。もちろん、トークンを紛失した場合、他の誰かがパスワードを知っている場合と同じ問題が発生しますが、それにより、トークンを紛失した場合にアクセスを取り消すことができるようにする方法や、おそらくトークン24時間を超えて生きるべきではないので、オフィスに来た次の日、IDを再度提示する必要があります。しかし、それでも、IDを示す人は1人だけです。
質問は古く、技術は進歩しています、これが現在の状態です：
JSON Web Token（JWT）は、Webアプリケーション環境でパーティー間でクレームを渡すためのJSONベースのオープンスタンダード（RFC 7519）です。トークンはコンパクトでURLセーフで、特にWebブラウザーのシングルサインオン（SSO）コンテキストで使用できるように設計されています。
これは、データベースまたは他の方法でユーザーに関連付けられているハッシュです。そのトークンを使用して、アプリケーションの認証に関連するコンテンツへのユーザーアクセスを認証および承認できます。クライアント側でこのトークンを取得するには、ログインが必要です。初回ログイン後、セッション、セッションIDなどのデータではなく、取得したトークンを保存する必要があります。これは、アプリケーションの他のリソースにアクセスするためのトークンであるためです。
トークンは、ユーザーの信頼性を保証するために使用されます。
Web APIリソースを保護するための現在最も推奨されるアプローチは、署名されたトークン（特定のユーザーを識別するのに十分な情報を含む）を使用してWeb APIサーバーでユーザーを認証することです。すべての要求。これはトークンベースの認証アプローチと呼ばれます。
トークンベースの認証は次のように機能します。
ユーザーはクライアントに名前とパスワードを入力します（クライアントとはブラウザーやモバイルデバイスなどを意味します）。
次に、クライアントはこれらの資格情報（ユーザー名とパスワード）を承認サーバーに送信します。
次に、承認サーバーはクライアントの資格情報（ユーザー名とパスワード）を認証し、アクセストークンを生成して返します。このアクセストークンには、ユーザーを識別するのに十分な情報と、トークンの有効期限が含まれています。
次に、クライアントアプリケーションは、HTTP要求のAuthorizationヘッダーにアクセストークンを含めて、トークンが期限切れになるまでResource Serverから制限されたリソースにアクセスします。
次の記事は、WEB APIにトークンベースの認証を実装する方法を段階的に示しています。
https://dotnettutorials.net/lesson/token-based-authentication-web-api/
新しいウェブサイトに登録すると、多くの場合、アカウントをアクティブにするための電子メールが送信されます。そのメールには通常、クリックするリンクが含まれています。そのリンクの一部であり、トークンが含まれています。サーバーはこのトークンを認識しており、それをアカウントに関連付けることができます。トークンには通常、有効期限が関連付けられているため、リンクをクリックしてアカウントをアクティブ化するのに1時間しかかかりません。Cookieまたはセッション変数では、これは不可能です。これは、顧客が電子メールのチェックに使用しているデバイスまたはブラウザーが不明であるためです。