TOKEN

TIL List

1)サーバベースの認証システム

トークンについて話す前に、サーバベースの認証システムについて理解する必要があります.
サーバベースの認証システムとは?
既存の認証システムはサーバベースの認証方式であり,サーバ側はユーザの情報を記憶する必要がある.ユーザーの情報を記憶するには、セッションを保持し、メモリ、ディスク、またはデータベースで管理する必要があります.サーバ・ベースの認証システムは、クライアントからの要求を受信した後も、クライアントの状態を維持し、Satefulサーバと呼ばれるサービスに使用します.たとえば、ユーザーがログインすると、セッションにユーザー情報が格納され、サービスが提供されるときに使用されます.
私たちがよく使うポータルサイトNAVERを例に挙げてみましょう.
ネイバーの検索機能のほか、会員登録が必要なネイバーメール、ネイバーペイなどのサービスを利用するため.
私たちはNAVERに会員登録が必要です.
NAVERでは,ユーザが会員登録した場合,そのユーザが記入した情報をどこかに保存すべきである.そうでなければ.
ユーザーはこのサービスを利用するたびに会員加入が必要となる不便に直面する.
では、上述したサーバベースの認証システムを用いてメンバーの情報を格納すると仮定する.
これらのシステムを導入したNAVERがその後20000人以上のユーザーを抱えている場合、どのような負担を負いますか?

1-1. データベースのオーバーロード

NAVERは、ユーザの認証時にこれらの情報を保存するために、これらの情報を任意の場所に保存する必要がある.
サーバベースの認証システムは、通常、これらの情報をメモリに格納します.
しかし、登録した会員が多くなると、メモリもたくさん消費されます.
メモリの負担は自然に増大します.
これを回避するために、ユーザの認証情報がデータベースに格納されていても、これは一時的な方法であり、データベースも
登録ユーザ数の増加に伴い,その負担も比例し,根本的な解決策にはならない.

1-2. 拡張性の複雑さ

NAVERにユーザを追加すると,同じ時間帯に多くのユーザがウェブサイトを利用するにつれて大量のトラフィックが発生する.
このような膨大な通信量を処理するためには,マルチプロセスやコンピュータの追加などによりサーバを拡張する必要がある.
このプロシージャでセッションを使用する場合は、これらのセッションを分散するシステムを設計する必要がありますが、このプロシージャは非常に複雑です.

1-3. Cross-Origin Resource Sharingのトラブル

Webアプリケーションでセッションを管理する場合、一般的なCookieは単一ドメインとサブドメインでのみ動作します.
そのため、複数のドメインでCookieを管理するのは面倒です.
サーバベースの認証システムには、これらの問題があります.
したがって、その後、トークンベースの認証システムが現れる.

2）トークンベースの認証システム

トークンベースの認証システムとは?
トークンベースの認証システムは、認証ユーザにトークンを発行し、サーバに要求するとトークンをヘッダに一緒に送信して検証する.これらのシステムは、ユーザーの認証情報をサーバまたはセッションに保持するのではなく、クライアントからのリクエストのみを処理します.すなわち、サーバベースの認証システムとは異なり、ステータスを保持しないため、ステータスなしの構造を有する.このようなトークンベースの認証方法により、ユーザがログインしているかどうかを考慮することなく、システムを簡単に拡張できる多くの問題を解決することができる.
遊園地を例にとると.
遊園地のチケットを購入するのではなく、スタッフが入場客リストに私の情報を書いてくれて、私が見学するたびに
そのリストで私の名前を見つけたことを想像してみてください.そうなると、スタッフは入場者に関するデータを大量に持ち続けなければなりません.
そしてこの入場者の名前を探すのにも時間がかかります.
つまり、非常に非効率です.
しかし、もし私にコインを送ってくれたら?
このコインを持っている人は当然入場者になるので、そのコインが存在するか否かを判断すれば終了です.

2-1. トークンベースの認証システムの処理手順

ユーザはIDとパスワードでログイン要求を送信する.

サーバ側は、この情報がデータベース内の情報と一致しているかどうかを確認します.

情報が正しい場合、サーバ側はSignedトークンをユーザーに発行します.(このタグがサーバから発行されたタグであることを示す)

クライアントはタグを保存し、サーバに特定のリクエストを送信するとタグとともに送信します.
(トークンを送信する方法はhttpリクエストヘッダにトークンを含めることである.)

サーバは、ユーザが送信したトークンを検証し、そのトークンに基づいて要求を送信します.

上には、クライアントがクライアントで、サーバーが遊園地のスタッフで便利です.

3) JWT (Json Web Token)

JWT ?
JWT(Json Web Token)は、Json形式でユーザ属性を格納するClaimベースのWeb Tokenである.JWTはタグ自体を情報として用い,自己包含的に安全に情報を伝達する.主に会員認証または情報伝達に使用されるJWTは、以下のように処理される.

3-1. JWTの構造

JWTはHeader、Payload、Signatureの3つの部分からなり、各部分はJSON形式でBase 64として符号化される.
(Base 64は暗号化文字列ではないことに注意してください)

3-2. HEADER

tokenのタイトルはtypeとalgの2つの情報から構成されている.algは暗号化ヘッダ(Header)ではなく、信号を復号するためのアルゴリズムを指定する.
入力:タグのタイプex)JWTを指定
Alg:HS 256(SHA 256)またはRSAなどの署名およびトークン検証のためのアルゴリズムを指定します.

{ 
 "alg": "HS256",
 "typ": JWT
 }

3-3. PAYLOAD

ペイロードにトークンに使用される情報フラグメントが含まれているクレーム.ここではJSON形式で多数の情報を入れることができます.
しかしPAYLOADは盗まれやすいので、重要な情報は絶対にPAYLOADに入れてはいけません.

3-4. PAYLOADのクレーム

クレームは、公開クレーム、非公開クレーム、登録されたクレームから構成されます.

公開クレーム

公開クレームは、その名の通り情報を公開するために使用されます.(URI形式を使用すればよい.)

{ "https://bsg-land.com": true }

非公開クレーム

非公開クレームは、その名の通り非公開情報のために使用されます.主にサーバとクライアントの間に任意の指定された情報を格納します.

{ "token_type": access }

3-5. Signature

署名は、トークンを符号化または検証する際に使用される固有のパスワードです.
SignatureはHeaderとPayloadをBase 64形式に符号化し、符号化された値を秘密鍵(SECRETKEY)でHeader定義アルゴリズムを復号し、これらの値をBase 64に再符号化する.
このようにして生成されたトークンは、HTTP通信の際に認証鍵という値として用いられる.

{ 
 "Authorization": "Bearer {생성된 토큰 값}",
 }

4)JWTの欠点?

まず、コインの最大の問題は、コイン自体に情報があることです.この点を常に覚えなければならない.
第二に、JWTは情報を格納しない無状態の形式であり、一旦生成されると、その後制御できない.
だから必ずコインの期限切れを!他のプレイヤーがこのトークンを使用して誤った動作を行うことを防止するには、指定します.