【仕組み解説】OAuthはどうやって安全にログインを実現しているのか — 認可の仕組みを図解

いい疑問だね。実はパスワードは一切渡していないんだ。あれは「OAuth」という仕組みを使っていて、たとえるなら「家の鍵を渡さずに、特定の部屋だけ使っていいよ」という許可証を発行しているイメージだよ。

たとえばマンションの管理人さんが「この人は3階の会議室だけ使っていいですよ」という一時的な許可証を発行してくれる感じだね。本人のパスワード（マスターキー）は一切見せずに、必要な範囲だけアクセスを許可する。これが「認可（Authorization）」という考え方だよ。

認証（Authentication）は「あなたは誰ですか？」を確認すること。認可（Authorization）は「あなたに何を許可しますか？」を決めること。OAuthは名前に"Auth"とついているけど、実は「認可」の仕組みなんだ。「この人が誰か」ではなく「このアプリにどこまでアクセスさせるか」を扱っているよ。

OAuthの「認可コードフロー」という流れを説明するね。登場人物は4者いるよ。まずユーザー（あなた）、クライアント（ログインしたいアプリ）、認可サーバー（GoogleやGitHub）、リソースサーバー（ユーザー情報を持つサーバー）。流れはこうだ。アプリが認可サーバーにリダイレクト → ユーザーがGoogleの画面で「許可」を押す → 認可サーバーが「認可コード」をアプリに返す → アプリがその認可コードを使って「アクセストークン」を受け取る → アプリがアクセストークンでリソースサーバーからユーザー情報を取得する、という流れだよ。

これはセキュリティ上すごく重要なポイントだよ。認可コードはブラウザのURL（リダイレクト）を経由して届くから、盗み見られるリスクがある。でも認可コード単体ではアクセスできなくて、アプリのサーバーが「クライアントシークレット」と一緒に認可サーバーに送って初めてアクセストークンに交換できるんだ。つまりアクセストークンはブラウザを経由せず、サーバー間の安全な通信で受け渡しされるよ。

その通り。アクセストークンは通常1時間程度で期限切れになるよ。そこで登場するのが「リフレッシュトークン」だ。これは長期間有効なトークンで、アクセストークンが切れたときに新しいものと交換できる。ただしリフレッシュトークンはサーバー側で厳重に管理する必要があるよ。あと、「スコープ」という概念も重要で、アクセストークンに「メールアドレスの読み取りだけ」「カレンダーの編集まで」のように権限範囲を設定できるんだ。

いい質問だね。スマホアプリやSPAのようにクライアントシークレットを安全に保管できないケースでは「PKCE（ピクシー）」という拡張を使うよ。アプリがランダムな文字列（code_verifier）を生成して、そのハッシュ値（code_challenge）を認可リクエストに添える。トークン交換時に元の文字列を送って、認可サーバーがハッシュを検証する。これで認可コードを横取りされても悪用できなくなるんだ。今ではサーバーサイドアプリでもPKCEの利用が推奨されているよ。

そこで登場するのが「OpenID Connect（OIDC）」だよ。これはOAuth 2.0の上に認証の仕組みを追加した規格なんだ。アクセストークンに加えて「IDトークン」というものが発行されて、その中にユーザーのID・メールアドレス・名前などが含まれている。つまり「Googleでログイン」は正確にはOAuth + OpenID Connectの組み合わせで実現されているんだよ。

もちろんあるよ。まず「リダイレクトURIの厳密な検証」が最重要。これが甘いと認可コードを攻撃者のサイトに送られてしまう。あとは「state パラメータ」でCSRF攻撃を防ぐこと、アクセストークンをlocalStorageに保存しないこと、スコープは必要最小限にすること。実装側としてはライブラリを自作せず、実績のあるOAuthライブラリを使うのが鉄則だね。OAuthは仕様自体がよくできているけど、実装のミスがセキュリティホールに直結するから、「仕組みを理解した上で、信頼できるライブラリに任せる」のがベストプラクティスだよ。