JWTとは?

JWT(JSON Web Token)とは何ですか?

JSON Web Tokenの略で、JSONオブジェクトを使って確実に情報を伝達するWeb標準です!
例えば、ログイン機能を考慮すると、ユーザがログインした後、後で会員のみがアクセスできるサービス領域でアイデンティティを確認するために、認証会員のトークンをサーバに渡すことができる.

なぜ認証が必要なのですか?

フロントエンドの観点から,認証とはユーザの登録,登録などの導入部分を指す.逆に,サーバ側の観点から,すべてのAPI要求に対してユーザ確認を行う操作である.

token_receive = request.cookies.get('mytoken')

ユーザAとユーザBがアプリケーションを使用すると仮定すると、2つのユーザの基本情報は異なり、持つコンテンツも異なる.したがって,サーバは,A,Bが要求したときに誰が要求したのかを明らかにすべきである.できなければ、自分の情報が他人に漏れる最悪の事態が発生する.したがって,アプリケーション(フロントエンド)は,自分が誰であるかを知る手がかり(トークン付きCookie)をサーバに送信する必要があり,サーバはこれらの手がかりを把握し(jwtを用いて復号する),要求ごとにデータを送信する必要がある.
現在、モバイルやWebサービスで最も一般的な通信方式はHTTP通信である.HTTP通信は,応答後に接続を切断すると,過去の情報を全く含まない.つまり、現在送信されているHTTPリクエストは、前回私の情報を含んだHTTPリクエストとは全く関係ありません.したがって,各HTTPリクエストには,エージェントが誰であるかに関する情報が必要である(認証が不要であれば不要である可能性がある).

セッションとCookieメソッド

進捗状況

ユーザーがログインします.

サーバは、アカウント情報を読み出してユーザを確認し、ユーザの一意のID値をセッション記憶に記憶し、それに関連付けられたセッションIDを発行する.

ユーザは、サーバからセッションIDを取得してCookieに保存し、検証が必要な各要求のヘッダにCookieを送信する.

サーバはCookieを受信し、セッションリポジトリで照合し、対応する情報を取得する.

認証が完了し、サーバはユーザに適したデータを送信する.

セッションCookie認証には、基本的にセッションストレージ(Redisを大量に使用)が必要です.セッションリポジトリは、ログイン時にユーザ情報を格納し、鍵としてセッションID値を作成します.その後,HTTPヘッダに装着し,ユーザに返す.そしてユーザはそれをCookieとして保存し、検証が必要な要求にCookie(セッションID)を入れる.
見送る.Webサーバは、セッションリポジトリからCookie(セッションID)を受信し、保存した情報と一致させて認証を完了する.
セッションはサーバが所有する情報であり,Cookieはユーザに送信するセッションを開く鍵(SESSION ID)である.Cookieのみを使用して認証を行うことは、サーバ上のリソースを使用しないことを意味し、クライアントが情報の検証を担当することを意味します.これでHTTPリクエストが盗まれると、略奪されてしまいます.したがって、カートや自動ログインの設定がセキュリティに関係していない場合は、非常に役立ちます.
その結果、セッションを使用してサーバに検証を担当させます.△ユーザーがハッカーに攻撃されるよりも、サーバがハッカーに攻撃されるほうがずっと難しい!

長所

セッション/クッキー方式は基本的にクッキーを媒介として認証を行う.したがって,Cookieを含むHTTP要求が途中で暴露されたとしても,Cookie自体(セッションID)には何の有効値もない.(重要な情報はサーバセッションにあるため、セッションIDには何の意味もありません)これはかなり安全に見えます.

ユーザAは1番、ユーザBは2番であり、このように固有のID値が発行される.これにより、サーバはクッキー値を受信すると、会員情報をいちいち表示する必要がなく、どの会員を表示することができ、サーバ上のリソースにアクセスしやすくなります.

短所

長所1ではビスケットを奪われても安全だという話が出ていますが、一つ問題があります.AユーザのHTTP要求がBユーザ(ハッカー)によってキャプチャされた場合、その中のCookieも完全に盗むことができる.また,Bユーザが盗んだクッキーを用いてHTTPリクエストを送信すると,サーバのセッションリポジトリがAユーザと誤認し,誤ってメッセージ(セッションハイジャック攻撃と呼ぶ…!)を送信する.

解決策

HTTPSを使用してリクエスト自体を盗むとしても、中の情報を読み取るのは難しい.

セッションに有効時間を追加します.

サーバはセッションストレージを使用するため、サーバは追加のストレージスペースを必要とし、負荷が増加します.

JWT方式

ユーザーがログインします.

サーバは、アカウント情報を読み出し、ユーザを確認し、ユーザに一意のID値を付与し、他の情報とともにPayloadに入れる.

JWTトークンの有効期間を設定します.

で暗号化されたSECRET KEYを使用してACCESS TOKENを発行します.

ユーザは、Access Tokenを受信して保存し、検証が必要な要求ごとにトークンをヘッダに送信する.

サーバは、トークンのVerify信号をSECRET KEYに復号し、動作および有効期間があるかどうかを確認する.

検証が完了すると、Payloadは復号化され、ユーザIDに適合するデータが取得される.セッション/Cookie方式との最大の違いは、セッション/Cookieがユーザの情報をセッションリポジトリに入れ、JWTがユーザの情報をトークンに入れることである.もちろん、クライアントにとっては、HTTPヘッダ上でセッションIDやトークンを送信するのは同じですが、サーバ側で暗号化して認証するか、個別のリポジトリを使用するかで違いが発生します.

長所

セッション/Cookieは、リポジトリを個別に管理する必要があります.ただし、JWTはパブリケーション後に検証するだけなので、追加のリポジトリは必要ありません.これは、ステータスレスサーバの作成に大きなメリットです.ここで、Statelessは、個別のリポジトリを使用しないこと、すなわちステータスを保存しないことを意味します.これにより、サーバの拡張やメンテナンスが容易になります.

は優れた拡張性を有する.トークンベースの他の認証システムにアクセスできます.例えば、Facebookログイン、Googleログインなどはトークンに基づいて検証されます.また、氏名や電子メールなどを受信する権限を得ることもできます.

ここの記事から見ると、JWTはセッション/Cookie方式よりも効率的に見えます.しかし、JWTにもいくつかの欠点がある.

短所

すでに発行されているJWTには取り返しがつかない.セッション/Cookieの場合、Cookieが悪用された場合、セッションをクリアできます.ただしJWTは一度リリースすれば有効期間が終わるまで使用できます.したがって,悪意のあるユーザは有効期間が過ぎる前に,興奮して情報を盗むことができる.

解決策

既存のAccess Tokenの有効期間を短縮し、Refresh Tokenの新しいトークンを発行します.そうなると、Access Tokenを奪われても、相対的にダメージを減らすことができます->OAuthというコンセプトの登場…!

ウェブページの情報は限られている.前述したように、Payloadは単独で暗号化されないので、復号すれば誰でも情報を確認することができます.(セッション/Cookieモードでは、ユーザのすべての情報がサーバのリポジトリに安全に保存されます.)したがって,ユーザの重要な情報をウェブページに置くことはできない.

これはJWTの道です.JWTの長さは、セッション/Cookie方式よりも長い.そのため、検証が必要なリクエストが多ければ多いほど、サーバのリソースが浪費されます.

コメントサイト

JWT