フロントエンドエンジニアの上條です。今回は、自分の学習のために認証・認可について調べてみた結果をまとめてみたいと思います。学習前の知識レベルとしては、認証・認可というワードは聞いたことあるけど違いがあやふやで自信を持って説明できないくらいでした。ようなライブラリに頼った実装で留まっていたため、認証・認可という本質的なところには届いてなかったように思います。認証・認可とはどちらもログイン周りの実装には欠かせない知識ですが、言葉が似ていて混乱します。説明すると以下のようになります。あたりが思い浮かびます)。ID/パスワードでログイン(認証)し、認証が完了した後に「このサービスがアクセスを求めています。アクセスを許可しますか?」のような確認画面が表示されると思います。アカウントに対してそのサービスへのアクセスを許可した=認可したことになります。なんとなく認証・認可についてイメージが湧くでしょうか。名前を見るのは以下の4つですが、実務でよく使われるのは後者の2つです。認証はデメリットとしてID/パスワードを暗号化せず通信するため盗聴すればログイン情報が分かってしまう点、通信する度にログイン情報を送る点が挙げられます。認証と変わらずデメリットとして存在します。認証・ダイジェスト認証は実務ではあまり使用されない印象です。毎回ログイン情報を送る点を解決するのがセッションベースの認証です。保存した状態で通信します。セッションIDが一致していれば本人とみなされるため、ログイン情報を通信に含めなくてよくなります。JWT)を使用します。保存した状態で通信します。サーバーは送られてきたアクセストークンが改ざんされていないか、有効期限が切れていないかなどを検証します。セッションベースとトークンベースの違いここまでだとログイン情報がセッションIDかアクセストークンに代わるだけで両者の違いが分かりづらいですが、大きな違いが2点挙げられます。1認証のための情報をサーバーに保存する必要があるかセッション:ある認証が完了したタイミングでユーザー情報とセッションIDを紐づける情報を保存します。サーバーに情報を持つためステートフルであると言われます。トークン:ないトークンのみで検証するため保存する必要はなく、ステートレスであると言われます。2セッションID・アクセストークンが無効化されるかセッション:されるログアウトしたり一定期間非アクディブだった場合はセッションが終了され、セッションIDも無効化されます。その際に1のサーバーに保存した認証のための情報も破棄されます。トークン:されないログアウトしたタイミングでブラウザに保存していたアクセストークンは破棄されますが、発行されたアクセストークンそのものは削除されません。そのためアクセストークンが流出すると第三者がアクセスできてしまいうため、アクセストークンの有効期限を短く設定することやトークン削除の実装がベストプラクティスとして推奨されています。認証は個人で使ったことあるなど断片的な知識は持っていましたが、今回学んだこととそれらが繋がったような感覚を持ちました。具体的な実装方法はこれから学んでいくつもりなので、その過程でも引き続き理解を深めていけるといいなと思っています。開発の実績と知見がありますフロントエンド開発の専門家である私たちが御社の開発チームに入ることで、バックエンドも含めた全体の開発効率が上がります。オンラインでのヒアリングとフルリモートでのプロセス支援にも対応しています。Momokaフロントエンドエンジニア。HTML/CSS/JavaScript/WordPressでのサイト制作からNext.js/TypeScriptなどを使ったWebアプリ開発、FigmaでのUIデザインまで広く経験しています。デザインエンジニアと名乗るのが夢です。