年末年始の慌ただしい雰囲気も落ち着き、ゆったりとした日々が流れているような気がします。
今年に入ってから「占い」というワードをすごく気にするようになりました🔮
昨年まで後厄だったため、今年はどんな年になるのだろうとずっと考えています。
ふと本屋でゲッターズ飯田さんの五星三心占いの本を目にしました。友人からよく当たる、と聞いたため次本屋に行ったときに購入してみようと思いました(その場で買えばいいのに・・・)
さて表題の件についてです。
自身でNextjsを色々触っていて、ログイン機能ってどんな仕組みなんだろうと思い実装しながら進めていると
トークン認証とセッション認証というものにぶつかりました。
調べてみてわかったことを少し備忘録としてまとめようと思いました！
セッションベース認証
一連のフローを下記画像でまとめてみました。
上記のようにセッションベース認証ではステートフルな認証になっています。
セッションベースではリクエストごとにSessionIDに紐づくユーザー情報を取得するので、ユーザーが多くなればなるほどサーバーに負荷がかかっていくと思われます。
トークンベース認証
こちらも同様に下記フローにてまとめてみました。
セッションベース認証とは反対にトークンベース認証はステートレスになっています。
サーバー側でTokenを保存したり、SessionIDのような情報を保存しておかなくていいので負荷がセッションベースのものよりかかりにくくなっています。
トークンベース認証が最強？
2つの認証のを見てみるとトークンベースのほうがスケーラブルにできて負荷が少なくていいじゃん！
となるかもしれませんが、やはりデメリットは存在します。
セッションベース認証の場合は、ログアウトした際にブラウザでSessionIDを別の値に更新し
サーバー側でもSessionIDとユーザー情報の紐づけを破棄します。そのためSessionID自体が無効となり他者がSessionIDを用いてユーザー情報等にアクセスすることはできなくなります。
トークンベース認証の場合はログアウトしたとしても、トークン自体の無効化はできておらず、Cookie等に保存しているトークンを削除するのみになります。そのため有効期限が切れていないトークンが他者にわたってしまうとリソース等にアクセスができてしまいます👿
トークン流出の防止策
トークン自体の無効化ができないのは痛手ですが、いくつか緩和する方法があります。
- トークンの有効期限を短くする
- トークンのブラックリストを持たせておく
- トークンのみの認証のメリットがなくなってしまう・・・
上記で少しでも緩和することができそうですが、トークンの取り扱いは難しそうな雰囲気がありますね。
どういった目的で認証を使用するかに寄って使い分けが必要となりそうですね。
終わりに
今回はWebアプリケーションにおける認証方法について少しまとめて見ました。
CookieについてやHTTP通信の仕組み、そもそも認証とはを色々学ぶことができたので小さな疑問が沢山の知識の蓄えになることが実感できてよかったです。
今回の記載内容に誤り等ありましたら、ご指摘お願いいたします🙇♂️
ついでに
認証のフローを作るときにdraw.ioというものを使ってみたのですが、GUIでER図等を簡単に作れたりテンプレートがあったりとエンジニアの方々が様々なものを図示するのにすごく便利なものだなと思いました！
気になる方はぜき下記URLからお試しください🖊️
draw.io: https://www.drawio.com/