OfferBoxの適性診断を比較｜AnalyzeU＋と360度の違い
認証の仕組みを面接で説明するには？認可・セッション・OAuthの違い
tennis0709closs@gmail.com
記事内に商品プロモーションを含む場合があります
認証の仕組みを面接で説明するなら、本人確認・ログイン状態の維持・操作の許可を分けて話すのがおすすめです。
ログインできたことと、すべてのデータを操作できることは別です。この違いを押さえると、Cookieやセッション、OAuthを単語の暗記で終わらせずに説明できます。
自作アプリで何を組み込み、どこまで動きを確かめたかを添えれば、ライブラリを使った経験も具体的な技術の話につながります。
本記事では、IT就活で技術質問に備える人に向けて、認証と認可の違い、ログイン状態が続く仕組み、安全対策、OAuth・OIDC、実装経験の伝え方を解説します。
【Contents】
認証と認可の違いを面接で説明する
認証は、申告されたアカウントの利用者かを確かめる処理で、認可は、その利用者に対象の操作を許すかを決める処理です。会員向けWebアプリなら、ログイン情報の確認と、個々のデータを読み書きする許可を分けて考えます。
ここでいう本人確認は、必ずしも実名や公的な身元を保証することではありません。そのアカウントに結び付いたパスワードや認証器を使えることと、現実の人物の身元を証明することは違います。
認証後の状態を次の通信へつなぐのがセッション管理です。Webではリクエストが分かれるため、一度のログイン結果をその後の操作にどう対応付けるかも必要になります。
例えば、自分のメモを編集できるアプリでも、別の利用者のメモまで編集できてよいわけではありません。ログイン済みという条件に加えて、そのメモを編集する権限があるかをサーバーで判断します。
面接では「誰かを確かめる」「状態をつなぐ」「何を許すか」の順に説明すると、実装の役割が伝わりやすくなります。ログイン画面の説明だけで終わらせず、ログイン後のアクセスまで一続きで捉えましょう。失敗の原因を考えるときも、この役割分担があれば、入力の照合に問題があるのか、権限の判断に問題があるのかを切り分けやすくなります。
技術経験の伝え方を応募先に合わせて準備したい人は、IT就活に対応するエージェントの支援内容も比較してみましょう。
ログイン状態が続く仕組み
サーバー側セッションを使うログインでは、パスワードの照合、IDの受渡し、操作の許可を順に処理します。画面が切り替わる裏側で、ブラウザーとサーバーが何を持つかを分けると理解しやすくなります。
- パスワードを照合する
- セッションIDを受け渡す
- 操作ごとに権限を確認する
パスワードを照合する
パスワードでログインする場合、サーバーは入力された値を、アカウントに保存した検証用の情報と照合します。
保存するのは平文のパスワードではなく、ソルトと計算コストを考慮した適切なパスワードハッシュです。ログイン時も、ハッシュを復号して元の文字列を取り出すわけではありません。
この処理を一般的なハッシュ関数1回だけで自作すると、パスワード向けの安全対策を落としやすくなります。使用するフレームワークや認証ライブラリの保存・検証機能を利用するのが基本です。
面接では、ライブラリ名だけでなく「何と何を照合し、成功するとどの処理へ進むか」まで説明しましょう。自分で暗号方式を設計したかのように話す必要はありません。
セッションIDを受け渡す
照合に成功したら、サーバーは利用者とセッションIDを対応付け、ログイン状態を管理します。ここでは、状態をサーバー側に置く方式を例に考えます。
Cookieはブラウザーがデータを保存し、条件に合うリクエストへ付けて送る仕組みです。セッションIDをCookieで受け取ると、その後の通信で同じIDをサーバーへ渡せます。
サーバーは受け取ったIDが有効かを調べ、対応する利用者を特定します。認証成功時にIDを更新することも大切で、ログイン前から同じIDを無条件に使い続ける設計にはしません。
Cookieとセッションを同じものとして覚えず、運ぶ仕組みと状態管理を分けて説明するのがおすすめです。IDが漏れればログイン状態を悪用されるおそれがあるため、パスワードとは別の保護が必要です。
操作ごとに権限を確認する
有効なセッションIDがあっても、その要求をそのまま実行してよいとは限りません。サーバーは利用者、対象データ、操作の組合せを確認します。
認可の確認は、対象となるリソースへのリクエストごとに必要です。自分のメモを読む権限と、別の利用者のメモを削除する権限は同じではありません。
画面上で編集ボタンを隠しても、サーバーへの要求自体を防げるわけではありません。表示の制御とは別に、サーバー側で許可・拒否を決める必要があります。
実装を説明するときは、ログイン成功の確認だけでなく「許してはいけない操作を拒否したか」まで伝えましょう。公開情報の閲覧など、未ログインでも許す操作があることも、認可の設計に含まれます。
CookieとJWTは何が違う？
CookieとJWTは、同じ種類の仕組みではありません。Cookieはブラウザーでの保存・送信に関わる仕組み、JWTは情報をまとめて伝える形式です。JWTをCookieに入れて運ぶ設計もあり、「Cookieを使うからJWTではない」とは言えません。
サーバー側セッションでは、ブラウザーが持つIDからサーバー上の状態を引き当てます。一方、署名付きJWTに利用者などの情報を含め、受け取った側で検証して使う設計もあります。保存場所、送信方法、状態の管理場所を別々に説明する必要があります。
JWTの署名は、内容の改ざんを検知するためのものです。署名しただけで内容を秘密にできるわけではなく、暗号化とは役割が異なります。JWTという形式を選んだだけで、保存や有効期限、失効の問題が自動的に解決することもありません。
面接で方式を比べるなら、どちらが新しいかではなく、状態をどこで持ち、どう検証し、利用をいつ止めるかを軸にしましょう。すべての認証を自分で実装するより、採用したライブラリがどの部分を担うかを確認する方が、自分のアプリの説明につながります。
| 対象 | 役割 | 考えること |
|---|---|---|
| Cookie | 保存・送信の仕組み | 何を、どの要求へ送るか |
| JWT | 情報を伝える形式 | 内容・署名・用途などの検証 |
| サーバー側セッション | 状態の管理方法 | IDと状態の対応・失効 |
認証を安全に保つ対策
ログイン成功後も、IDの漏洩や期限切れを考える必要があります。Cookieの扱い、ログアウト、MFAは、それぞれ守る対象が異なります。対策の名前と防げる範囲を結び付けて理解しましょう。
- Cookieの送信と読取りを制限する
- 期限切れとログアウトを扱う
- 異なる要素でMFAを組み合わせる
Cookieの送信と読取りを制限する
セッションIDをCookieで扱うなら、Cookieの属性も説明できるようにしておきましょう。
SecureはHTTPSでの送信、HttpOnlyはスクリプトからのCookie読取り制限、SameSiteはクロスサイトでの送信制御に関わります。同じCookieに付ける設定でも、目的は異なります。
HttpOnlyを付けてもXSSそのものが起きなくなるわけではありません。SameSiteもサイト構成や必要な通信を踏まえて選ぶため、それだけですべてのCSRF対策が完了するとは説明しない方が正確です。
属性を3つ暗記するより、漏洩や意図しない送信のどこを抑えるかまで結び付けましょう。HTTPS、入力や出力の安全な扱い、必要なCSRF対策など、別の層の対策も残ります。
期限切れとログアウトを扱う
セッションは、一度作ったら永久に有効というものではありません。一定時間操作がない場合や、利用開始からの時間などを基準に、有効期限を管理します。
サーバー側セッションのログアウトでは、ブラウザーのCookie削除に加えてサーバー側のセッション無効化が重要です。ブラウザーから消すだけでは、すでに漏れたIDを使い続けられる可能性が残ります。
利用者がログアウトした後の画面だけでなく、以前のログイン状態で要求したときに操作を拒否するかも確認対象になります。端末ごとの状態をどう扱うかは、サービスの要件によって変わります。
面接では「ログアウトボタンを作った」から一歩進めて、何を無効にし、再利用をどう止めたかを説明しましょう。自分が確かめていない端末や条件まで成功したことにしないのが大切です。
異なる要素でMFAを組み合わせる
MFAは、多要素認証のことです。知っているもの、持っているもの、生体の特徴など、異なる種類の要素を組み合わせます。
パスワードと別の暗証番号を2回入力しても、どちらも知識の要素であり、それだけでは多要素になりません。画面の数や操作回数ではなく、何を使って確認するかが区別の基準です。
一方、パスワードに加えて所持する認証器を使う方式などは、要素の組合せとして説明できます。ただし、MFAであればどんなフィッシングも防げるわけではなく、方式ごとに性質が異なります。
MFAを説明するときは、増やした要素と、残るリスクを分けて話すのがおすすめです。認証を強くしても、ログイン後の認可やセッション管理が不要になるわけではありません。
OAuthとOIDCの役割を分ける
外部サービスを使うログインは、アクセスを許すOAuthと、認証結果を伝えるOIDCを分けて説明します。どのサービスが何を確認し、自分のアプリが何を受け取るかを整理することが大切です。
OAuthはアクセス権を委任する
OAuth 2.0は、あるアプリに保護された情報などへの限定的なアクセスを認めるための枠組みです。利用者のパスワードをそのアプリへ直接渡すこととは区別します。
例えば、写真サービスの一部の情報へ別のアプリからアクセスする場合、許可した範囲のアクセストークンを使います。その途中で利用者のログインが起きることはありますが、OAuth単体を利用者の認証結果を伝える仕様と同一視はできません。
現在の設計を説明する際は、認可コードを使うフローとPKCEを中心に押さえるとよいでしょう。PKCEはコード交換を守る仕組みで、利用者の本人確認そのものではありません。
「OAuthでログインしました」だけで終わらず、何へのアクセスを、誰が、どの範囲で許したかを話しましょう。古い方式を名前だけ並べるより、実際に採用した流れを説明する方が具体的です。
OIDCは認証結果を受け取る
OIDC（OpenID Connect）は、OAuth 2.0の上に利用者の認証を扱う層を加えた仕様です。クライアントは認証結果に関する情報をIDトークンで受け取ります。
IDトークンはクライアントへ認証結果を伝え、アクセストークンは保護されたAPIなどへのアクセスに使うという用途の違いがあります。IDトークンをAPI向けの許可証として安易に流用しません。
IDトークンは、受け取っただけで信用できるものではありません。署名に加えて、発行者、対象クライアント、有効期限などを仕様に沿って検証し、必要な追加条件も認証ライブラリの処理と照合します。
外部ログインを説明するなら、受領・検証・自サービス内の権限確認を分けましょう。外部で認証に成功しても、自分のアプリで管理者として操作できるかは、別の判断です。
認証の実装経験を面接で伝える
面接では、用語の定義だけでなく、自分が組み込んだ処理と確かめた動作を話すと説明が具体的になります。仕組みの説明、確認した条件、担当していない範囲を切り分けて準備しましょう。
処理の流れを短く答える
短く答えるときは、最初に自分のアプリが採用した方法を示し、入力から操作許可までを順に話します。すべての方式を列挙する必要はありません。
サーバー側セッションの例なら、パスワードの照合、IDによる状態維持、対象データへの認可は別の処理です。画面が遷移したことだけでは、それぞれの役割を説明したことになりません。
下の回答例は、該当する処理を実装した場合の説明例です。自分のアプリで使っていない方式や、検証していない対策をそのまま借りないようにしましょう。
最初の回答を短くしたうえで、深掘りされた処理を自分の実装へ戻して話すのがおすすめです。どの関数や設定が担当するかを確かめておくと、用語の言い換えだけになりにくくなります。
実際に担当・確認した範囲に合わせる回答例
「私のアプリでは、ライブラリでパスワードを照合した後、サーバー側のセッションを作り、IDをCookieで返します。以後の要求ではIDの有効性を調べ、データの所有者と操作権限を確認します。ログインしただけで他人のデータを編集できないよう、認可を別に実装しています。」
失敗する条件まで説明する
動作確認は、ログインに成功するケースだけでは不十分です。自分のアプリや許可された検証環境で、失敗すべき条件も確かめます。
別の利用者のデータへの操作、期限切れ、ログアウト後の再利用は、それぞれ異なる確認条件です。どの条件で何を拒否する設計なのかを、期待する結果と対応付けます。
実際の結果が期待と違った場合は、認証、状態の判定、認可のどこを直したかを記録します。第三者のサービスや、利用許可のないデータを試験対象にする必要はありません。
確認条件・結果・変更点を残してから、面接で話す範囲を決めましょう。READMEには仕組みと検証範囲を整理し、パスワードや本物のセッションID、トークンを掲載しないようにします。
あわせて読みたい
GitHubを就活で見せる準備｜README・公開設定・提出の手順
ライブラリ任せの範囲を明確にする
認証ライブラリを使ったことと、仕組みを理解していないことは同じではありません。安全性が重要な処理ほど、検証された機能を適切に組み込む判断が大切です。
ライブラリが担当した照合やトークン検証と、自分が担当した設定・画面・認可・動作確認は分けられます。自分で書いていない処理まで実装したと説明せず、接続した部分を具体化します。
まだ実装していない場合は、理解した処理と、これから確かめる条件を伝えます。用語を知っていることを本番運用の経験へ広げる必要はありません。
経験が小さくても「何を選び、どう確認し、何が残ったか」を話せる状態を目指しましょう。自分の経験をどの企業へどう伝えるか迷う場合は、学習状況に合う選考支援も比較してみてください。
実際に担当・確認した範囲に合わせる回答例
「パスワードの照合はライブラリを使いました。自分はセッションの設定と、メモの所有者を確認する処理を担当しています。ログアウト後の利用は確認しましたが、複数端末の扱いはまだ検証していません。」
参考資料
ABOUT ME
IT就活のWebマーケティング領域を支援してきました。
よくあるプログラミングスクールをはじめたら「月収100万円」みたいな嘘のマーケティング活動をしている会社に嫌気が指す思いでいたので、当ブログを設立。
未来を担う学生が、大人に食い物にされないように、「IT就活における社会の真理」をお伝えするブログです。
よくあるプログラミングスクールをはじめたら「月収100万円」みたいな嘘のマーケティング活動をしている会社に嫌気が指す思いでいたので、当ブログを設立。
未来を担う学生が、大人に食い物にされないように、「IT就活における社会の真理」をお伝えするブログです。
