はじめに
トークンベースの認証は、今日のweb上のどこでも顕著です。 APIを使用しているほとんどのweb企業では、トークンは複数のユーザーの認証を処理する最良の方法です。
アプリケーションにトークンベースの認証を選択する際には、いくつかの非常に重要な要素があります。 トークンの主な理由は次のとおりです:
- ステートレスでスケーラブルなサーバー
- モバイルアプリケーション準備
- 他のアプリケーションに認証を渡す
- 余分なセキュリティ
トークンベース
あなたが遭遇した主要なAPIまたはwebアプリケーションは、最も可能性の高いトークンを使用しています。 Facebook、Twitter、Google+、GitHub、および非常に多くのようなアプリケーションは、トークンを使用します。
のは、それがどのように動作するかを正確に見てみましょう。
なぜトークンが来たのか
トークンベースの認証がどのように機能し、その利点を見る前に、過去に認証が行われた方法を見なければなりません。
サーバーベースの認証(従来の方法)
HTTPプロトコルはステートレスであるため、ユーザー名とパスワードでユーザーを認証すると、次の要求でアプリケーションは私たちが誰であるかを知らないことを意味します。 私たちは再び認証する必要があります。
私たちのアプリケーションに私たちが誰であるかを記憶させる従来の方法は、ユーザーのログイン情報をサーバーに保存することです。 これは、セッション上でいくつかの異なる方法で、通常はメモリに、またはディスクに保存することができます。
web、アプリケーション、およびモバイルアプリケーションの台頭が起こるにつれて、この認証方法は、特にスケーラビリティに問題を示しています。
サーバーベース認証の問題
この認証方法でいくつかの大きな問題が発生しました。
- : ユーザーが認証されるたびに、サーバーはサーバー上のどこかにレコードを作成する必要があります。 これは通常、メモリ内で行われ、多くのユーザーが認証すると、サーバーのオーバーヘッドが増加します。
- スケーラビリティ:セッションはメモリに格納されるため、スケーラビリティに問題があります。 クラウドプロバイダーがアプリケーションの負荷を処理するためにサーバーの複製を開始すると、セッションメモリに重要な情報が含まれていると、ス
- : データを複数のモバイルデバイスで使用できるようにアプリケーションを拡張したいので、cross-origin resource sharing（CORS）について心配する必要があります。 AJAX呼び出しを使用して別のドメイン（APIサーバーへのモバイル）からリソースを取得すると、禁止された要求で問題が発生する可能性があります。
- CSRF:クロスサイトリクエストフォージェリ(CSRF)に対する保護も行います。 彼らはすでに銀行サイトを言うと、これは他のサイトを訪問するときの利点を取ることができると認証することができますので、ユーザーはCSRF攻撃の
これらの問題では、スケーラビリティが主な問題であり、別のアプローチを試してみることは理にかなっていました。
トークンベースの仕組み
トークンベースの認証はステートレスです。 私たちは、サーバー上またはセッションにユーザーに関する情報を保存していません。
この概念だけで、サーバーに情報を保存する必要がある問題の多くが処理されます。
セッション情報がないと、アプリケーションはユーザーがログインしている場所を気にせずに、必要に応じてマシンを拡張して追加できます。
この実装は異なる場合がありますが、その要点は次のとおりです:
- ユーザーがユーザー名/パスワードでアクセスを要求する
- アプリケーションは資格情報を検証します
- アプリケーションは、クライアントに署名されたトークンを提 このトークンは、ステートレスHTTP要求の考え方を維持するために、HTTPヘッダーで送信する必要があります。 また、
Access-Control-Allow-Origin: *を使用してすべてのドメインからの要求を受け入れるようにサーバーを設定する必要があります。 ACAOヘッダーに*を指定することについて興味深いのは、HTTP認証、クライアント側SSL証明書、cookieなどの資格情報を要求が提供できないことです。私たちの情報で認証され、トークンがあれば、このトークンで多くのことを行うことができます。
許可ベースのトークンを作成し、これをサードパーティのアプリケーション（たとえば、使用したい新しいモバイルアプリ）に渡すこともできます。
トークンの利点
ステートレスでスケーラブルな
トークンはクライアント側に格納されます。 完全にステートレスで、スケーリングする準備ができています。 私たちのロードバランサーは、どこにも状態やセッション情報がないので、私たちのサーバーのいずれかにユーザーを渡すことができます。
ログインしていたユーザーのセッション情報を保持する場合、そのユーザーをログインしたのと同じサーバーに送信し続ける必要があります（セッションアフィニティと呼ばれます）。
これは、一部のユーザーが同じサーバーに強制され、トラフィックが大量に発生する可能性があるため、問題をもたらします。
でも心配しないように！ トークン自体がそのユーザーのデータを保持しているため、これらの問題はトークンにはありません。
セキュリティ
cookieではなくトークンが要求ごとに送信され、cookieが送信されないため、CSRF攻撃を防ぐのに役立ちます。 特定の実装がクライアント側のcookie内にトークンを格納している場合でも、cookieは認証メカニズムではなく単なるストレージメカニズムです。 私たちはセッションを持っていないので、操作するセッションベースの情報はありません！
トークンも設定された時間が経過すると期限切れになるため、ユーザーはもう一度ログインする必要があります。 これは、私たちが安全に滞在するのに役立ちます。 トークン失効の概念もあり、特定のトークンや、同じ承認付与に基づいてトークンのグループさえも無効にすることができます。
拡張性（友人の友人と権限）
トークンを使用すると、他のユーザーと権限を共有するアプリケーションを構築できます。 たとえば、ランダムなソーシャルアカウントをFacebookやTwitterなどの主要なものにリンクしています。
サービス（Bufferとしましょう）を介してTwitterにログインすると、BufferがTwitterストリームに投稿できるようになります。
トークンを使用することにより、サードパーティのアプリケーションに選択的な権限を提供する方法です。 ユーザーが自分のデータへのアクセスを別のアプリケーションに提供したい場合は、独自のAPIを構築し、特別な許可トークンを渡すこともできます。
複数のプラットフォームとドメイン
先ほどCORSについて少し話しました。 私たちのアプリケーションとサービスが拡大すると、私たちはあらゆる種類のデバイスやアプリケーションへのアクセスを提供する必要があります（私たちのアプリは間違いなく人気になるでしょう！).
私たちのAPIがデータを提供するだけで、CDNから資産を提供する設計選択を行うこともできます。 これにより、アプリケーションのクイックヘッダー構成を設定した後にCORSが発生する問題がなくなります。
Access-Control-Allow-Origin: *私たちのデータとリソースは、ユーザーが有効なトークンを持っている限り、どのドメインからの要求でも利用できます。
標準ベース
トークンを作成するときには、いくつかのオプションがあります。 フォローアップ記事でAPIを保護するときは、このトピックについてさらに詳しく説明しますが、使用する標準はJSON Webトークンです。
この便利なデバッガとライブラリチャートは、JSON Webトークンのサポートを示しています。 あなたはそれが様々な言語にわたってサポートの偉大な量を持っていることがわかります。 これは、将来的にそうすることを選択した場合、あなたが実際にあなたの認証メカニズムを切り替えることができることを意味します！
結論
これは、トークンベースの認証の方法と理由を見ただけでした。 セキュリティの世界では常にそうであるように、各トピックにははるかに多くのものがあり、ユースケースごとに異なります。 私たちも、同様に独自の会話に値するスケーラビリティ上のいくつかのトピックに鳩。
これは高レベルの簡単な概要でしたので、見逃したことや問題についての質問を自由に指摘してください。
次の記事では、JSON Webトークンの構造を見ていきます。
注：ACAOヘッダー情報とCSRFの説明の追加（記事情報についてはEmily Starkに感謝します）