OIDC（OpenID Connect）とは、Webサービス間でユーザー認証を標準化するためのプロトコルであり、シングルサインオン（SSO）をはじめとした認証連携の実現に利用されています。

OIDCを活用することで、ユーザーはサービスごとにID・パスワードを個別に管理・記憶する必要がなくなり、利便性の向上が期待できます。

また、パスワードの使いまわしによって生じるセキュリティリスクの低減にも役立ちます。

本記事では、OIDCの概要やメリット・デメリットなどを解説します。

「OIDCとは何か」「導入することでどのようなメリットがあるのか」などを知りたい方はぜひご一読ください。

OpenID Connect（OIDC）とは

OpenID Connect（OIDC、オー・アイ・ディー・シー）とは、インターネット上の複数のサービス間で、ユーザーの「認証情報」を安全にやり取りするための標準プロトコルです。

OIDCを導入することで、一度のログインで、OIDCに対応している複数の企業内アプリケーションやWebサービスへログインできるようになります。

これにより、ユーザーはサービスごとに個別にID・パスワードを管理・入力する必要がなくなり、利便性の向上が期待できます。

「認証」と「認可」の違い

OIDCを理解する上で重要なのが、「認証」と「認可」の違いです。

この2つは混同されがちですが、役割は明確に異なります。

このように、認証は「誰なのか」を確認すること、認可は「何をしてよいか」を決めることという違いがあります。

OIDCは、このうち「認証」を担う仕組みです。

OAuthとの関係

OAuthとは、Webサービス同士を安全に連携させるための仕組みで、主に「認可」の役割を担います。

この仕組みを利用することで、ユーザーは個別のサービスにID・パスワードを直接渡すことなく、特定の操作権限を安全にサービス間で委任できます。

混同されがちな2つの仕組みですが、それぞれの役割は以下のように整理できます。

OAuthはサービス間で操作権限を安全に受け渡すことを目的として設計されており、「このユーザーは誰なのか」を正確に識別する認証プロトコルではありません。

そこで登場したのが、「OIDC」です。

OIDCは、OAuth2.0が提供する枠組み（アクセストークン管理や通信フロー）を基盤としつつ、その上に「利用者が誰であるか」を確認するための認証レイヤーを追加したプロトコルです。

つまり、OAuthが担う「何をしてよいか（操作やアクセス権限）」の制御に加え、「その操作を許可されているのは誰か」を明確に証明できるようにしたのが、OIDCです。

これにより、OAuth単体では標準的に扱われていなかったユーザーの本人確認を共通の方法で実現できるようになり、結果として、複数のサービス間で共通に利用できる安全なログインの仕組みの標準化が可能となりました。

OIDCの仕組み

OIDCを活用して複数のサービス間で認証情報を連携する場合、一般的に以下の流れで処理が行われます。

IDトークンとは、ユーザーが正しく認証されたことをクライアントに通知するためのトークンです。

これにより、クライアントは「このユーザーが誰であるか」を確認できます。

一方でアクセストークンは、クライアントが必要なAPIへアクセスするための権限を示すトークンです。

この2種類のトークンをクライアントに返すことで、「このユーザーは確かに本人である」という認証、「必要な操作を行なってよい」という認可の両方が完了し、OIDCを用いた安全なサービス連携が可能となります。

OIDCが生まれた背景

インターネット技術の発展とクラウドサービスの普及により、ユーザーは利用するサービスごとに、複数のアカウントを管理するようになりました。

その結果、ユーザー側ではID・パスワードを管理・入力する手間が生じ、サービスを提供する企業側においても、サービスごとに独自に認証基盤を構築・運用するコストが課題となっています。

こうした状況を改善するために登場したのが、「OAuth 2.0」という認可の仕組みです。

OAuthは、外部サービスとの安全な連携を実現するための仕組みとして広く普及しましたが、もともと「認可」を目的としたプロトコルであるため、ユーザー本人の「認証」を厳密に扱う設計にはなっていません。

つまり、ログイン用途としては十分とは言えず、本人確認の重要性やログインの効率化が求められる近年において、課題が生じていました。

さらに、スマートフォンやクラウドサービスの普及によって、以下のようなニーズが一気に高まりました。

こうした要求に対して、前述の通り、従来のOAuthでは十分に対応できなくなっていました。

そこで、これらの課題を解決し、「認証のための標準プロトコル」を世界的に統一するために生まれたのが 「OIDC（OpenID Connect）」です。

OIDCはOAuth 2.0をベースにしつつ、ログインに必要な要素（ユーザーIDの検証方法、IDトークンの仕様、安全なフローなど）を追加することで、認可と認証の役割を明確に分離しました。

その結果、OIDCは「安全で扱いやすい認証プロトコル」として世界中のサービスで採用され、現在ではWeb・モバイル問わずログイン機能のデファクトスタンダードとなっています。

OIDCのフロー

OIDCでは、クライアント（アプリ）がユーザーの本人情報を取得するために、OpenID Provider（OP） にリクエストを送り、IDトークンやアクセストークンを受け取ってログイン処理を行います。

このとき、OIDCには複数の認証方式（フロー）が用意されており、アプリの種類やセキュリティ要件に応じて使い分けられます。

本記事では、以下の3つのフローを解説します。

詳しく見ていきましょう。

暗黙的なフロー

暗黙的なフローとは、クライアントが認可サーバーを経由せず、 OpenID Providerからのリダイレクト応答を通じて、アクセストークンやIDトークンを直接受け取る方式です。

この方式では、サーバーサイドの実装が不要で、仕組みも比較的シンプルなため、導入しやすいという特徴があります。

また、ユーザーがトークンをすぐに取得できるため、処理が軽量でレスポンスが速いというメリットもあります。

一方で、トークンがURLの一部としてブラウザに渡される仕組みのため、盗み見や改ざんといったリスクが高く、安全性の確保が難しいという課題があります。

さらに、より安全な認可フローで利用されるPKCEを適用できないため、近年求められるセキュリティ要件には十分に対応できない点も問題とされています。

なおPKCEとは、トークンを発行する際の正当性を検証する仕組みのことで、認可コードの盗用を防ぎ、より安全な認証・認可を実現するための拡張仕様のことです。

認可コードフロー

認可コードフローとは、認可コードを介してトークンを取得する方式です。

この仕組みでは、ユーザーがWebアプリからにリダイレクトされてログインを行い、認証が完了すると、認可コードが付与された状態でWebアプリに戻ります。

その後、Webアプリは取得した認証コードを用いて、アクセストークンやIDトークンと交換します。

認可コードフローは、本記事で紹介する3つのフローのうちで、セキュリティ強度が最も高く、安心して認証処理を行うことが可能な方式です。

また、Webアプリに加え、モバイルアプリやSPA（シングルページアプリケーション）など、さまざまなアプリケーション形態に対応できる柔軟性も備えています。

一方で、トークンの取得処理をサーバー側で行う必要があるため、フロントエンドだけでは完結しない点には注意が必要です。

その結果、構成がやや複雑になり、開発コストや実装の手間が増える場合がある点が課題として挙げられます。

ハイブリッドフロー

ハイブリッドフローは、暗黙的なフローと認可コードフローを組み合わせた方式です。

このフローでは、IDトークンを先にフロントエンドへ返却し、アクセストークンは後から認可コードを用いてサーバー側で安全に取得します。

メリットとしては、ユーザーがログインした直後にユーザー情報を画面へ反映できるため、レスポンスが早く、ユーザー体験を損なわない点が挙げられます。

さらに、アクセストークンの取得をサーバー側で行うため、セキュリティ面では認可コードフローと近く、高い安全性を確保することが可能です。

一方で、設計や実装がやや複雑になりやすく、多くのサービスではこの方式を必要としないケースが多いことが課題として挙げられます。

利用シーンが限定的であるため、実際に採用されるケースは比較的少ないのが現状です。

OIDCのメリット

OIDCを利用することで、次のようなメリットを期待できます。

詳しく確認していきましょう。

セキュリティを強化できる

OIDCは、従来のID・パスワードによるログイン方式と比較して、以下のようなセキュリティ上の利点があります。

また、OIDCは多要素認証（MFA）などの認証方式とも組み合わせて、より強固なセキュリティ体制を構築することも可能です。

前述の通り、OIDCはWebサービス間でユーザー認証を標準化するためのプロトコルであり、本人確認の具体的な方式については、IdP（ユーザーの認証を行う認証基盤）側に任せています。

そのため、IdP側で多要素認証などの強固な本人確認方式を採用し、その認証結果を複数のサービス間で共通に利用できるようにすることで、より安全な認証基盤を構築することが可能になります。

認証情報の管理の負担が軽減できる

OIDCを採用することで、ユーザーはサービスごとに個別にID・パスワードを管理・入力する必要がなくなります。

これにより、パスワードの使いまわしによって生じるセキュリティリスクを低減することが可能です。

また、企業・組織のセキュリティ担当者にとっても、従業員のパスワードの紛失や忘れに都度対応する必要がなくなるため、運用負荷の軽減が期待できます。

実装しやすい

OIDCは標準化されたプロトコルであり、豊富なライブラリやSDKが提供されているため、比較的容易に実装することが可能です。

また、以下のような特徴があるため、開発者が個別に細かな設定を行う必要はほとんどありません。

この結果、セキュリティと利便性を兼ね備えた認証機能を短時間で導入できるという点が、OIDCの大きなメリットといえるでしょう。

OIDCのデメリット

OIDCのデメリットとして、IDトークンが不正に利用された場合の影響範囲が大きいことが挙げられます。

仮にIDトークンが盗まれた場合、OIDCによって連携している複数のWebサービスに不正アクセスされる危険性があります。

また、リダイレクトURLの設定ミスやPKCE未導入、トークンの不適切な保存など、OIDCを正しく実装・運用できていない場合には、セキュリティ事故につながる可能性もあります。

このように、OIDCは非常に強力な認証基盤を実現できる一方で、正しい理解に基づいた設計と丁寧な実装・運用が欠かせない技術であるといえます。

まとめ

本記事では「OpenID Connect（OIDC）」をテーマに、その概要やメリット・デメリットなどを解説しました。

OIDCは、管理すべきID・パスワードが増加している近年において、利便性とセキュリティを両立できる非常に有効な認証方式です。

ただし、本記事で紹介した通り、取り扱いや設定ミスなどに起因するリスクも存在します。

そのためOIDCを採用する際は、PKCEの導入やリダイレクトURLの厳密な検証といったセキュリティ対策をあわせて実施することが重要です。