前回の続きと、この講義の役割
前回のQ-03では、ログイン状態を続ける二つの方式と、その失効の考え方を見ました。今回はさらに手前に戻ります。そもそも、自分のアプリでパスワードを持たずにログインさせる方法を扱います。Q-02で「認証は自作せず、実績ある仕組みに任せる」という定石を学びましたが、その最も具体的な実現手段が、この外部ログインです。自作を避ける判断が、ここで実際の形になります。
このスライドのポイント
- Q-03: ログイン状態を続ける方式（セッション・トークン）と、その失効の考え方を学んだ
- 今回: そもそも自分のアプリでパスワードを持たずにログインさせる方法へ
- Q-02の「認証は自作しない」という定石の、最も具体的な実現手段がこれ
外部ログインとOAuthの定義
外部ログインとは、「◯◯でログイン」のように、利用者がすでに持っている別サービスのアカウントで本人確認を行う方式です。OAuthは、その代表的な取り決めで、K-01で学んだAPIの一種として、認証結果の受け渡し方を定めた規約です。流れはこうです。まず自分のアプリが利用者を外部サービスへ案内し、利用者はそこでログインと同意を行い、その結果の証明だけが自分のアプリへ返ってきます。ここで最も大切な点を一つだけ覚えてください。パスワードは自アプリを一度も通らない、ということです。
このスライドのポイント
- 外部ログイン＝「◯◯でログイン」のように、利用者がすでに持つ別サービスのアカウントで本人確認する方式
- OAuth＝その代表的な取り決め。K-01のAPIの一種として、認証結果の受け渡し方を定めた規約
- 流れ: 自アプリ → 外部サービスへ案内 → 利用者がそこでログインと同意 → 結果の証明だけが自アプリへ返る
- 最重要: パスワードは自アプリを一度も通らない
なぜ外部ログインが必要か
この仕組みを知らないと、Q-02で学んだ「認証を自作しない」の、具体的な代わりが何なのかが分かりません。自作を避けたくても、では何に任せればよいのかが分からなければ、結局はあぶない自前のログインをAIに書かせてしまいます。もう一つ、外部ログインの途中で表示される同意画面が何を意味するのかも読めなくなります。メールアドレスだけを渡すのか、それ以上を渡すのか。その判断ができないまま進めると、目的に対して必要以上の情報を受け取る構成になりがちです。
このスライドのポイント
- Q-02の「認証を自作しない」の、具体的な代わりが何かを知るため
- 何に任せるか分からなければ、結局あぶない自前ログインを書かせてしまう
- 同意画面が何を意味するか（メールだけか、それ以上か）を読めないと、必要以上の情報を受け取る構成になりがち
三者の構造
構造を、三者の関係で捉えます。登場するのは、利用者、自分のアプリ、そして外部の認証サービスの三者です。ここで注目してほしいのは、利用者がパスワードを入力する相手は、外部サービスだけだということです。外部サービスは本人確認を済ませ、自分のアプリには「本人確認が済んだ」という証明だけを返します。つまりパスワードは、外部サービスの中だけを通り、自分のアプリには一度も届きません。この一方向の流れが、外部ログインの安全性の土台になっています。
このスライドのポイント
- 登場するのは三者: 利用者／自分のアプリ／外部の認証サービス
- 利用者は外部サービスに対してだけパスワードを入力する
- 外部サービスは本人確認を済ませ、自アプリには「本人確認済みの証明」だけを返す
- パスワードは外部サービスの中だけを通り、自アプリには一度も届かない
経費アプリでの具体例と三つの利点
具体例として、経費アプリを社内アカウントでログインさせる構成を考えます。この構成には利点が三つあります。一つ目は、パスワードを預からないため、万一自分のアプリのデータが漏れても、パスワードの漏えいという最悪の事態を外部へ切り離せることです。二つ目は、利用者が新しいパスワードを覚える必要がないことです。三つ目は、退職者が出たときに、元の社内アカウントを停止すれば、それに連動して自分のアプリにも入れなくなることです。これは、Q-03で学んだ失効を、外部の仕組みに任せられるということです。
このスライドのポイント
- 経費アプリを社内アカウントでログインさせる構成
- 利点1: パスワードを預からない → 自アプリのデータが漏れても、パスワード漏えいという最悪の事態を外部へ切り離せる
- 利点2: 利用者が新しいパスワードを覚える必要がない
- 利点3: 退職者は元の社内アカウント停止で連動して入れなくなる（Q-03の失効の外部化）
技術サンプル: 三者フロー図
スライドの図は、三者の間を情報がどう流れるかを示しています。読むときの要点は二つです。一つ目は、パスワードが通るのは外部サービスの中の一区間だけで、自分のアプリが受け取るのは、本人確認済みの証明と、氏名やメールなどの最小限の情報だけだという点です。二つ目は、同意画面は「何を渡すか」の契約であり、後のQ-09で扱う、情報を持ちすぎないという考え方の入口になっている点です。AIへの質問例です。「この外部ログイン連携で、自アプリはどの情報を受け取りますか。それは必要最小限ですか」と確認してください。
混同しやすい概念
混同しやすいのは、「外部ログイン」と「パスワードを外部に教えること」です。外部ログインは、認証という仕事を外部サービスに委ねる正規の仕組みで、自分のアプリはパスワードに一切触れません。一方、どこかの画面に他サービスのパスワードを入力させる行為は、まったくの別物で、絶対にしてはいけませんし、利用者にもさせてはいけません。正規の流れでは、パスワードの入力は必ず、そのサービス自身の画面の中だけで行われます。
このスライドのポイント
- 「外部ログイン（認証を委ねる）」vs「パスワードを外部に教える（絶対にしない・させない）」
- 外部ログイン＝正規の仕組み。自アプリはパスワードに一切触れない
- どこかの画面に他サービスのパスワードを入力させる行為＝まったくの別物。危険
バイブコーディングでの確認点
バイブコーディングでの確認点です。認証を組み込むときは、第一候補として「外部ログイン、またはBaaSの認証機能を使う」とAIに明示的に指定します。Q-02で見たとおり、認証の自作は危険だからです。あわせて、外部から要求する情報の範囲が最小限になっているかも確認します。質問例です。「この認証で要求している情報の範囲は、このアプリの目的に対して最小限ですか」と聞いてください。
このスライドのポイント
- 認証を組み込むときは、第一候補として「外部ログイン、またはBaaSの認証機能を使う」とAIに明示指定する
- 理由: Q-02で見たとおり、認証の自作は危険
- あわせて、外部から要求する情報の範囲が最小限かを確認する
- 質問例:「この認証で要求している情報の範囲は、このアプリの目的に対して最小限ですか」
一問一答とまとめ
最後に一問一答です。外部ログインで、自分のアプリがパスワードに触れる瞬間はいつでしょうか。……答えは、「ない」です。触れないことこそが、この仕組みの本質でした。三十秒でまとめます。外部ログインは、認証を外部サービスに委ね、パスワードを自分のアプリに通さない方式です。利点は、漏えいリスクと失効の両方を外部へ預けられることでした。次回のQ-05では、ログインした後の「何をしてよいか」、つまり認可の実装へ進みます。関連資料は「Supabase入門ハンドブック」「AIアプリのセキュリティ超入門」です。
このスライドのポイント
- 一問一答:「外部ログインで、自アプリがパスワードに触れる瞬間は？」→ 答: ない（触れないことが仕組みの本質）
- 30秒まとめ: 外部ログインは認証を外部に委ね、パスワードを自アプリに通さない方式。利点は漏えいリスクと失効の外部化
- 次回: Q-05 ログイン後の「何をしてよいか」＝認可の実装へ
- 関連資料: 「Supabase入門ハンドブック」「AIアプリのセキュリティ超入門」
