Webサービスを利用する際、「Googleでログイン」や「LINEでログイン」といったボタンを見かけない日はありません。ユーザーにとっては、新しくパスワードを作成・管理する手間が省ける便利な機能ですが、その裏側では「認証」と「認可」を受け渡す高度なセキュリティ技術が働いています。
第33回で学んだ「認証（本人確認）と認可（権限付与）の違い」の概念が、インターネット上でどのように受け渡されているのか。今回は、その基盤となる「OAuth 2.0」と「OpenID Connect（OIDC）」の役割の違いについて、エンジニアが押さえておくべきポイントを整理します。
OAuth 2.0（オーオース）：権限を安全に委託する仕組み
OAuth 2.0は、一言で言えば「認可（権限付与）」のためのフレームワークです。
あるアプリ（連携先）が、ユーザーに代わって「別のサービス（GoogleやGitHubなど）のリソース」にアクセスすることを許可するための仕組みです。
OAuth 2.0の仕組み
- 認可のリクエスト： アプリがユーザーに対し、「あなたの代わりにGoogleフォトの写真を読み取ってもいいですか？」と許可を求めます。
- ユーザーの同意： ユーザーはGoogleのサイト上でログインし、アプリへの権限付与に同意します。
- アクセストークンの発行： Googleは、アプリに対して「アクセストークン」という期限付きの合鍵を渡します。
この仕組みの最大のメリットは、ユーザーが「自分のパスワードを連携先のアプリに教えなくて済む」ことです。合鍵だけを渡すことで、万が一そのアプリが攻撃を受けても、Google本体のパスワードが漏れることはありません。
OpenID Connect（OIDC）：OAuth 2.0を「認証」へ拡張
OAuth 2.0は非常に便利ですが、あくまで「合鍵（認可）を渡す」ためのものであり、その鍵を持っているのが「誰か（認証）」を証明する機能は本来持っていませんでした。そこで、OAuth 2.0の上に「身元証明」の層を追加したのがOpenID Connect（OIDC）です。
OIDCの特徴：IDトークンの導入
OIDCでは、アクセストークンに加えて「IDトークン」というデジタルデータが発行されます。これには、ユーザーの識別番号、名前、メールアドレスなどの情報が含まれており、かつ発行元の署名が付与されています。
なぜ「OAuthでログイン」という言葉は厳密には間違いなのか？
エンジニアの会話では「OAuthでログイン機能を実装する」という表現がよく使われます。しかし、厳密な定義では、OAuthは「認可（リソースへのアクセス権譲渡）」のためのものであり、ログイン（認証）のためのものではありません。
かつては、OAuthのアクセストークンが手に入る＝本人がログインしたはずだ、と見なす「疑似認証」という手法もありましたが、これはセキュリティ上の脆弱性を生む原因となりました。現在、安全に他サイトのアカウントでログイン（ソーシャルログイン）を実装する場合は、OpenID Connectを使用するのが標準となっています。
連携先のアプリはこのIDトークンを検証することで、「このユーザーは間違いなくあの人だ」と確信を持ってログイン（認証）処理を行うことができます。
ソーシャルログイン導入のメリットとセキュリティ
ソーシャルログインは、単に便利なだけでなく、システム全体のセキュリティ向上にも寄与します。
- パスワード漏洩リスクの回避： ユーザーのパスワードを自社で保管しないため、データベースからパスワードが盗まれるリスクそのものを排除できます。
- 強力な認証の継承： Googleなどが提供する「多要素認証」を突破してきたユーザーのみを受け入れられるため、自前で高度な認証機能を開発するコストを抑えられます。
- アカウント作成のハードル低下： 新規登録時の入力項目が大幅に減るため、ユーザーの離脱を防ぐことができます。
まとめ
ソーシャルログインは、OAuth 2.0とOpenID Connectという2つの技術が組み合わさることで、利便性と安全性を両立させています。
- OAuth 2.0は、特定のデータにアクセスする「認可」の仕組み。
- OpenID Connectは、その人が誰かを証明する「認証」の仕組み。
第35回で解説する「シングルサインオン（SSO）」では、この仕組みをさらに発展させ、企業内の複数のシステムに一度のログインでアクセスできるようにするSAMLなどの技術についても触れていきます。
コメント