Cookie#

昔のやり方は、Cookie に直接保存する。サーバーストレージはまだそんな安いの状況下で、たくさんのウェブサイトはユーザーの登録そういうインフォメーションを変化してサインして Cookie に保存する。

変化やサインは、md5+salt、または secret を使って双方向の暗号化するとかの方法。

ウェブサイトに二回アクセスとしたら、Cookieに指定のkeyのvalueを検証する、それはただしかどうか。

こうやっていいところは： サーバーストレージ占有なし、Cookie はユーザーの情報です

こうやって悪いところは： ユーザー情報盗むはやすい、特にhttpsなし、中間者攻撃されたら、悪い人にログインされたことはできる。 また、別々に保存するのデータを改ざんされるはやすい。

Session#

計算力とストレージの速い発展、問題は次々に現れた。保存希望のユーザー情報はますます多くなる、Cookie のサイズ制限は少ない。

原理的には、Session は Cookie です。

サイトにアクセスとき、サーバーから唯一の Session ID を配ってCookie に保存する。ログインのとき、この Session ID による、サーバーに Session Object を作る、このオブジェクトにuser idとか、状態というユーザーの情報を保存している。

Session ID は Session Object を作るのときに配れも可能です、Session IDの作る方法は時間によるに限らない、sidの唯一を保証すればいい。

Session Object のストレージ場所も選べる。Sessionはとても大事ですと思われなら、mysql に保存するは可能です、そうではない場合は、redis に、メモリにも可能です。

だから、Sessionはとてもフレキシブル。

Session は過去の技術ではない、今はたくさんのウェブサイトに使われている。その原因は、httpしか問題いません。Internet Explorer >= 10 の場合も CORS に Cookie の伝送が可能ですから、問題ない。

いいところ： クライエントサイド sid しか見えない

悪いところ： 情報を取得する、一つ query 必要です。 盗むも可能ですが、Session / Cookie の問題ではない、http の問題です、httpで何も見える。

いいと悪いは時代に応じるです、Cookie に保存するときは、サーバーの計算力は低い、memcacheやredisもない、Sessionの時間はかかる、今はこれは決して悪いところじゃない。

Session と Cookie はフロントエンドにとって何をする必要はない、サーバーは Set-Cookie の http header で sid と Cookie の更新を完成することはできる。

Token Based#

上記２つの方法は、２つの異なるアイデアを表しています。一つは情報をクライエントサイドに保存する、一つはサーバーにする。

フロントエンドとバックエンドを分けるときは、上記の２つアイデアも Cookie なしに進化する。

一つは Session Token を取って、JSON、または 他のhttp header に伝送する

一つは JWT（JSON Web Token） 情報をクライエントサイドに保存するというアイデアを表す。Cookie とちょっと似ているけど，情報を base64 に変化して、secretでサインして、一緒に token になる。

クライエントサイドに保存するのいいところは： 情報はクライエントに保存しているから、コードに直接処理はできる、ロードバランスとかの心配いらない。 また、Session の期限切れば、データベースに delete の必要がある。

悪いところは： 情報多くなるとき、Token は長くなる、http request は大きいになる、伝送の時間がかかる。

JWT の payload は base64 コーディングする、誰か標準に通じれば、内容を見られます。

Token Based 認証はフロントエンドに保存して、コーディングは必要です、一般はlocalStorageで。 だから、Token Based 認証は XSS に攻撃される可能性はある、Cookie Based 認証は CSRF に攻撃される可能性はある。

結論#

いくつかの単語をすべての場合に要約することはできません、Token と Cookie また 情報をクライエントサイドに保存するとサーバーにするの場合を想像する、どんな方法を採用しようか、現業務を基にして、ちょっと長いのビジョンで選択を考える。