OIDC

概要

OIDC（OpenID Connect）は、OAuth 2.0 の上に「本人確認」の層を載せた標準プロトコルです。「Google でログイン」「Apple でサインイン」といったボタンの裏側で実際に動いているのはこの OIDC で、あなたが Google に対して行ったログインの結果を、別のアプリが安全に受け取れるようにします。パスワードを各サービスに預ける代わりに、信頼できる一箇所（IdP）で認証を済ませ、その「証明書」を持ち回る仕組みと言い換えられます。

鍵になるのは、OAuth が認可（何をしてよいかの許可）のプロトコルであって、認証（誰であるかの確認）の仕組みではない、という区別です。OAuth のアクセストークンは「この権限で API を呼んでよい」という切符にすぎず、「誰がいつどうやってログインしたか」は保証しません。OIDC はこの欠けていた部分を、ID トークンという新しい成果物を追加することで補いました。ID トークンの実体は署名付きの JWT で、「誰が・どの IdP で・いつ・どのアプリ向けに」認証されたかが記された、検証可能なログインの証明書です。

現在、コンシューマ向けのソーシャルログインから企業の SSO 基盤まで、新規に構築される認証連携の大半は OIDC が採用されています。Web の認証を学ぶうえで、OAuth とセットで避けて通れない語彙です。

なぜ生まれたか

OAuth 2.0 が普及すると、多くの開発者が「アクセストークンが取れた＝ユーザー本人を確認できた」とみなして OAuth をログインに流用し始めました。しかしこれは危険な誤用でした。アクセストークンは「誰に発行されたか」を検証する標準的な手段を持たないため、攻撃者が別のアプリ向けに発行された正規のトークンを盗んで持ち込むと、被害者としてログインできてしまう — いわゆるトークン置き換え攻撃が成立します。各社が独自の回避策を重ねた結果、「Facebook ログイン」「Google ログイン」の実装はすべて微妙に異なる方言だらけになりました。

一方、それ以前から存在した認証連携の標準（OpenID 2.0 や SAML）は、独自の仕様体系や XML 処理の重さから、モバイルアプリや API 中心の開発と相性が良くありませんでした。そこで 2014 年、すでに広く実装されていた OAuth 2.0 の枠組みをそのまま流用し、その上に「認証結果を標準形式で受け渡す」薄い層を定義したのが OpenID Connect です。認可のフローに ID トークンを一枚追加するだけで、方言だらけだったソーシャルログインが相互運用可能な標準になりました。

詳細

OAuth に何が追加されたのか

OIDC のフローは、OAuth の認可コードフローとほぼ同じ形をしています。違いは3点に集約されます。第一に、認可リクエストの scope に openid を含めることで「これは認証の要求である」と宣言すること。第二に、トークンエンドポイントの応答にアクセストークンと並んで ID トークンが返ること。第三に、ユーザーのプロフィール情報を取得する UserInfo エンドポイントが標準化されていることです。役割の名前も認証の文脈に合わせて、認可サーバは「OpenID プロバイダ（OP）」、クライアントは「リライング・パーティ（RP、依拠当事者）」と呼ばれます。

流れを追うと、ユーザーがログインボタンを押す（1）と、RP はブラウザを OP の認可エンドポイントへリダイレクトさせます（2）。OP がユーザー本人を認証し（3〜4）、認可コードを添えて RP へ戻します（5）。RP はサーバ間通信で認可コードをトークンに交換し（6〜7）、このとき ID トークンを受け取ります。ここまでは OAuth と同じ骨格ですが、次の「ID トークンの検証」（8）が OIDC の核心です。検証を終えた RP は、自前のセッションを開始してログイン状態を確立します。

ID トークンの中身と検証

ID トークンは署名付きの JWT で、ペイロードには標準化されたクレーム（主張）が並びます。主要なものは、発行者を示す iss、ユーザーの一意な識別子である sub、トークンの宛先アプリを示す aud、発行時刻 iat と有効期限 exp、そして実際に認証が行われた時刻 auth_time です。RP はこれらを必ず検証します — 署名が OP の公開鍵で検証できるか（公開鍵暗号による改ざん検知）、iss が期待した IdP か、aud が自分宛か、有効期限内か。特に aud の検証こそが、OAuth 単体で問題になったトークン置き換え攻撃への直接の回答です。他のアプリ向けに発行されたトークンは aud が一致しないため、盗んで持ち込んでも受理されません。

もうひとつ実務上重要なのが nonce です。RP が認可リクエストに使い捨てのランダム値を含めると、OP はそれを ID トークンに埋め込んで返します。RP は自分が送った値と一致するかを確認することで、リプレイ攻撃（過去のトークンの再利用）を防ぎます。CSRF 対策の state パラメータと合わせ、「自分が始めたログインフローの結果であること」を確かめる仕掛けです。

エコシステムを支える周辺仕様

OIDC が広く普及した理由のひとつは、運用を楽にする周辺仕様が最初から揃っていたことです。Discovery は、IdP の各エンドポイントや対応機能を /.well-known/openid-configuration という URL から機械可読な JSON で取得できる仕組みで、RP は IdP のドメイン名さえ知っていれば設定の大半を自動化できます。署名検証用の公開鍵も JWKS というエンドポイントから取得でき、IdP 側の鍵ローテーションに RP が自動で追従できます。Dynamic Client Registration によるクライアント登録の自動化や、複数サービスからの一斉ログアウトを扱うログアウト系仕様も定義されています。

実務での位置づけと落とし穴

実装面では、Auth0・Okta・Microsoft Entra ID・Keycloak といった IdP 製品がすべて OIDC に対応しており、自社サービスに「◯◯でログイン」を組み込む場面でも、社内システムを SSO に統合する場面でも、まず OIDC が第一候補になります。企業向けでは先行規格の SAML が今も現役ですが、モバイルや SPA、API 連携を含む新規構築では OIDC が標準的な選択です。SPA やモバイルアプリから使う場合は、OAuth と同様に PKCE 付きの認可コードフローを使います。

典型的な落とし穴は、ID トークンとアクセストークンの役割の混同です。ID トークンは「RP がログインを確認するためのもの」であり、API 呼び出しに使うのはアクセストークンです。逆に、リソースサーバが ID トークンを API の認可に受け付けてしまうのも誤りです。また、ID トークンの検証（署名・iss・aud・exp・nonce）を一部でも省略すると OIDC の安全性は根元から崩れるため、自前実装を避けて実績のあるライブラリを使うことが強く推奨されます。トークンの有効期限が切れた後のログイン状態の維持には、リフレッシュトークンやセッション管理仕様を組み合わせます。