Token認証
#WIP
#??
こういうフローのこと「JWT認証」って呼ぶの?
必ずしもJWTである必要がないので、もっと良い名前がありそうな気がする
OpenID Connectとはどこが異なるのか
OIDCの方の理解をしないといけないmrsekut.icon
JWTを使ったSession管理のようなもの
この記事で通常のsession管理との違いが整理されている
Artifact
トークンにはメタデータを保持せずIDのみ。メタデータはサーバ側のストレージに持つことが一般的
ServerがSessionIdを発行し、それをCookie経由でやり取りする
server側には、session idとuser情報を結びつけて保存しておく必要がある
つまりstatefulになる
Assertion
メタデータをすべて内包する形式。JWTはその代表格。
serverがsessionIdの代わりに、JWTを発行し、responseする
そのJWTには
userIdなどの情報が入っている
有効期限などの情報も入れたりする
server側の秘密鍵で署名もしくは暗号化する
clientは認証が必要な時にそのJWTも一緒に送る
serverはそのJWTを見れば、誰から送られてきたのかわかる
user情報を取り出せるので
server側はsessionを管理する必要がないので、statelessになる
この「Artifact」と「Assertion」という分類名もどこまで一般的なのか不明 #??
どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ? - co3k.org
JWT認証は良くない、みたいなないよう
この記事に対する反論
JWT認証、便利やん? - ブログ
JWT形式を採用したChatWorkのアクセストークンについて - Chatwork Creator's Note
良い
問題点
個別にserver側でsessionの無効化ができない
ユーザの能動的なログアウトで、sessionが失効されない
攻撃者からするとSession Hijackingしやすくなる
秘密鍵を知っていれば任意のユーザに対するSession Hijackingが可能
トークンのサイズが大きくなる場合があり、 cookie にデータを保存しにくい
http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/