OIDC（OpenID Connect）とは？仕組み・OAuthとの違いをわかりやすく解説

OIDC（OpenID Connect／オープンアイディー・コネクト）とは、OAuth 2.0を拡張してつくられた認証プロトコルです。OAuth 2.0が「アプリにどのリソースへのアクセスを許可するか（認可）」を扱うのに対し、OIDCはその上に「ログインしているのは誰か（認証）」を確認する仕組みを追加します。これにより、アプリケーションは「IDトークン」を使ってユーザーの本人確認を行え、シングルサインオン（SSO）やソーシャルログイン（「Googleでログイン」など）を安全に実現できます。本記事では、OIDCの仕組み、IDトークン、OAuth 2.0やSAMLとの違い、認証フロー、そして実際の活用例までをわかりやすく解説します。

OIDC（OpenID Connect）とは

まず、OIDCがどんな技術で、なぜ生まれたのかを整理します。

OIDCの定義

OIDCは、OAuth 2.0の仕様をベースにしながら、認可（Authorization）だけでなく認証（Authentication）も行えるようにした仕様です。OAuth 2.0のフローに「openid」というスコープの指定と、IDトークンの発行という認証の要素が加わったもの、と理解すると分かりやすいでしょう。サービス側はこのIDトークンを検証することで、「アクセスしているユーザーが誰なのか」を確認できます。RESTベースのシンプルな仕組みで、既存のOAuth 2.0との相性がよい点も特徴です。

OIDCに登場する3つの役割

OIDCは、3つの登場人物で成り立ちます。1つ目はエンドユーザー（ログインする人）、2つ目はOpenIDプロバイダー（OP＝IDトークンを発行する認証サーバー。GoogleやMicrosoftなど）、3つ目はRelyingParty（RP＝ユーザーを受け入れるアプリ側）です。RPがOPに認証を依頼し、OPがユーザーを認証してIDトークンを返し、RPがそれを検証してログインを成立させる、という関係になります。

身近な例：ソーシャルログイン

OIDCがもっとも身近に使われているのが、「Googleでログイン」「Appleでサインイン」といったソーシャルログインです。この場合、Google等がOpenIDプロバイダーとしてユーザーを認証し、アプリ側はGoogleから発行されたIDトークンを通じてユーザー情報を受け取ります。ユーザーは新しくアカウントを作らずに、既存のアカウントでさまざまなサービスにログインできるようになります。

IDトークンとは：OIDCの核心

OIDCを理解するうえで欠かせないのが、IDトークンです。

IDトークンはJWT形式で発行される

IDトークンは、OIDCによって発行されるJWT（JSON Web Token）形式のトークンで、「誰がログインしたか」を示します。OpenIDプロバイダーの秘密鍵で署名されているため、受け取った側は署名を検証することで、トークンが本物で改ざんされていないことを確認できます。IDトークンには、発行者（iss）、ユーザーの識別子（sub）、対象者（aud）、有効期限（exp）といった情報（クレーム）が含まれます。

IDトークンとアクセストークンの違い

OIDCを扱うときに混同しやすいのが、IDトークンとアクセストークンです。役割がはっきり異なります。IDトークンは「誰がログインしたか」を示す認証用のトークンで、OIDCが発行します。アクセストークンは「どのリソースにアクセスしてよいか」を示す認可用のトークンで、OAuth 2.0の仕組みで使われます。ログイン処理にはIDトークン、API呼び出しにはアクセストークン、と用途を分けて使うのが基本です。

OIDCとOAuth 2.0の違い

OIDCを理解するには、土台となるOAuth 2.0との関係を押さえることが近道です。

OAuthは「認可」、OIDCは「認証」

OAuth 2.0は、ユーザーの代わりにアプリがAPIなどのリソースにアクセスするための「認可」のプロトコルです。「このアプリに、あなたのデータへのアクセスを許可しますか？」というアクセス権の委譲を扱います。一方OIDCは、そのOAuth 2.0を拡張し、「ログインしているのは誰か」という「認証」を実現します。OAuthが「何にアクセスできるか」を、OIDCが「誰がアクセスしているか」を扱う、という役割分担です。

両者は補完関係にある

OAuth 2.0とOIDCは対立するものではなく、互いを補い合う関係です。実際の運用では、OIDCで認証（ログイン）を行いつつ、OAuth 2.0のアクセストークンでAPIアクセスを認可する、という構成が一般的です。OIDCはOAuth 2.0の上に成り立っているため、両者を組み合わせて認証と認可の両方を処理できます。

OIDCとSAMLの違い

OIDCと並んでSSO（シングルサインオン）を実現する技術に、SAMLがあります。両者はよく比較されます。

SAMLは、OAuthとは独立した認証連携の仕組みで、XML形式でメッセージをやり取りします。主に企業内で、社員が1回のログインで複数の社内アプリにアクセスする用途で広く使われてきました。一方OIDCは、JSON/JWTベースで軽量なため、モバイルアプリや消費者向けWebサービスのログイン、ソーシャルログインなどで広く利用されています。どちらもSSOを実現できますが、新規のWeb・モバイル向けにはOIDC、既存の企業システム連携にはSAML、という使い分けが一般的です。SAML側の認証フローやIdP・SPの仕組み、署名検証の勘所はSAMLとは？認証フロー・IdP/SPの仕組みとOAuth・OIDCとの使い分けを実装視点で解説で詳しくまとめています。

OIDCの認証フロー

OIDCにはいくつかのフローがありますが、もっとも代表的で推奨されるのが「認可コードフロー」です。

認可コードフロー（Authorization Code Flow）

認可コードフローの流れは次の通りです。まずユーザーがアプリ（RP）にアクセスすると、OpenIDプロバイダー（OP）の認可エンドポイントにリダイレクトされます。ユーザーがログインすると、OPは「認可コード」を発行してアプリに返します。アプリはその認可コードをOPのトークンエンドポイントに送り、引き換えにIDトークンとアクセストークンを受け取ります。トークンの受け渡しがサーバー間通信で行われるため、ブラウザ上に機密情報を露出しにくく、セキュリティ面で優れています。

PKCEによる安全性の強化

近年は、認可コードフローにPKCE（Proof Key for Code Exchange）を組み合わせるのが標準的なベストプラクティスです。PKCEは、認可コードが第三者に横取りされても悪用されないようにする仕組みで、特にモバイルアプリやSPA（シングルページアプリケーション）で重要です。これから新規にOIDCを実装するなら、認可コードフロー＋PKCEを基本に考えるとよいでしょう。

OIDCを採用するメリット

認証を信頼できるプロバイダーに任せられる

OIDCを使うと、パスワードの管理をアプリ側で抱えず、GoogleやMicrosoftなど信頼できるOpenIDプロバイダーに任せられます。これにより、自前でパスワードを保管することによる情報漏えいリスクを減らせます。

トークンの改ざんを検知できる

IDトークンは署名付きのJWTとして発行されるため、署名を検証することでトークンの改ざんや不正利用を検出できます。JWTそのものの構造や署名アルゴリズム、保存場所と失効の設計はJWTとは？構造・署名検証の仕組みとセッション・OAuth/OIDCとの違いを実装視点で解説で詳しく扱っています。発行者・対象者・有効期限などのクレームを検証することで、安全にログイン処理を行えます。

SSOやMFAと統合しやすい

OIDCは標準化されたプロトコルのため、シングルサインオン（SSO）や多要素認証（MFA）との統合が容易です。OIDCとSSO・IDaaSの関係は、認証・ID管理の全体像で俯瞰できます。複数のサービスで共通の認証基盤を構築でき、ユーザーの利便性とセキュリティを両立させやすくなります。

OIDCの活用例：GitHub Actionsとクラウドの連携

OIDCは、ソーシャルログインだけでなく、CI/CD（継続的インテグレーション／デリバリー）の認証にも活用されています。代表的なのが、GitHub ActionsとAWS・GCPなどのクラウドを連携させるケースです。

シークレットレスでクラウドにアクセスできる

従来、GitHub Actionsからクラウドを操作するには、AWSのアクセスキーなど長期有効な認証情報をGitHubのSecretsに登録する必要がありました。OIDCを使うと、GitHubが実行ごとに短命なIDトークンを発行し、それをクラウド側に提示して一時的なアクセス権を得られます。静的なキーを保存しなくて済むため、漏えいリスクとキー管理の手間を大きく減らせます。

仕組みの概要

GitHub Actionsのワークフローでid-token: writeの権限を指定すると、GitHubがIDトークンを発行します。クラウド側（AWSのIAM Identity Provider、GCPのWorkload Identity Federationなど）は、そのトークンの署名とクレーム（発行元・リポジトリ・ブランチなど）を検証し、条件に合致すれば一時的なアクセス権を付与します。トークンに含まれるリポジトリ情報などを条件にできるため、「特定のリポジトリのmainブランチからのみ許可」といったきめ細かな制御が可能です。AWS・GCPなど複数のクラウドで同じ仕組みを使えるのも、業界標準であるOIDCの利点です。クラウドの認証基盤としては、AWS CognitoのようにOIDCに対応したマネージドサービスもあります。

まとめ：OIDCは「認証」を担うOAuth 2.0の拡張

OIDC（OpenID Connect）は、OAuth 2.0を拡張し、「ログインしているのは誰か」という認証を実現する標準プロトコルです。核心となるのは署名付きのIDトークン（JWT）で、これを検証することでユーザーの本人確認を行います。OAuth 2.0が「認可（何にアクセスできるか）」を、OIDCが「認証（誰がアクセスしているか）」を担い、両者は補完関係にあります。SSOを実現する点ではSAMLと似ていますが、OIDCはJSON/JWTベースで軽量なため、Web・モバイル・ソーシャルログインで広く使われています。認証フローは認可コードフロー（PKCE併用が推奨）が基本で、ソーシャルログインからCI/CDのクラウド認証まで、現代的なシステムの認証基盤として幅広く活用されています。これから認証を設計するなら、OIDCの仕組みを正しく理解しておくことが、セキュリティと利便性の両立につながります。

よくある質問（FAQ）

Q. OIDCとOAuthの違いは何ですか？

A. OAuth 2.0は「認可（どのリソースにアクセスしてよいか）」を扱うプロトコルで、OIDCはそれを拡張して「認証（誰がログインしているか）」を実現します。OIDCはIDトークンを発行する点がOAuth 2.0との大きな違いです。

Q. OIDCとSAMLはどちらを使うべきですか？

A. 新規のWebアプリやモバイルアプリ、ソーシャルログインにはJSON/JWTベースで軽量なOIDCが向いています。既存の企業システム同士のSSO連携では、導入実績の豊富なSAMLが使われることが多いです。

Q. IDトークンとアクセストークンの違いは何ですか？

A. IDトークンは「誰がログインしたか」を示す認証用のトークン（JWT）で、アクセストークンは「どのリソースにアクセスしてよいか」を示す認可用のトークンです。用途を分けて使います。

Q. OIDC認証とは何ですか？

A. OIDC（OpenID Connect）を使ってユーザーの本人確認を行う認証方式のことです。OpenIDプロバイダーが発行する署名付きのIDトークンを検証することで、ユーザーが誰かを安全に確認します。

Q. OIDCはどんな場面で使われていますか？

A. 「Googleでログイン」などのソーシャルログイン、複数サービスのシングルサインオン（SSO）、GitHub Actionsとクラウドを連携させるCI/CDの認証など、幅広く使われています。あわせて、情報統制についても解説しています。