OpenID Connectとは。仕様を開発者向けに整理

Q: OpenID ConnectとOAuth 2.0の違いは何ですか？

OAuth 2.0はデータへのアクセスを許可するための認可の仕組みで、成果物はアクセストークンです。OIDCはその上に構築された「いま操作しているのは誰か」を伝える認証の仕組みで、成果物はIDトークンです。アクセストークンは持ち主が誰かを証明しないため、ログイン機能にはOIDCのIDトークンが必要です。

Q: IDトークンとアクセストークンはどう違いますか？

アクセストークンはリソースにアクセスできる鍵で、IDトークンは誰が・いつ・どの相手向けに認証されたかを署名付きで表した証明書です。アクセストークンだけを根拠にログインを実装すると、他人のトークンを流用したなりすましを許す穴が生まれます。

Q: state・nonce・PKCEは全部必要ですか？

全部必要です。stateはCSRF、nonceはIDトークンのリプレイ、PKCEは認可コードの横取りと、防ぐ攻撃がそれぞれ異なり代用できません。PKCE（RFC 7636）は現在、サーバーサイドWebアプリを含む全クライアントで推奨され、デジタル認証サービスでも必須です。

Q: インプリシットフローを使ってもいいですか？

新規採用は推奨されません。インプリシットフローはIDトークンがブラウザに露出します。現在の標準は、ブラウザには使い捨ての認可コードだけを通し、IDトークンをサーバー間通信で受け取る認可コードフロー+PKCEです。

Q: OIDCでログインできれば犯収法の本人確認になりますか？

なりません。OIDCが保証するのは当人認証（操作しているのが登録済みの本人であること）で、犯収法が求める身元確認（実在し申告どおりの人物であること）とは別物です。両者をつなぐ拡張仕様としてOIDC4IDAがあり、verified_claimsクレームで確認済み属性と検証方法を受け渡せます。

Q: OIDC実装を外注するとき、何を確認すればよいですか？

認可コードフロー+PKCEの採用、IDトークンの署名・iss・aud・exp・nonceの全項目検証、redirect_uriの完全一致登録、アカウントキーにemailではなくsubを使うこと、JWKSの鍵ローテーション追従の5点を質問することをおすすめします。回答が曖昧な場合は認証まわりの設計レビューを別途挟むのが安全です。

ログイン機能や本人確認システムの要件定義・見積もり確認の場で、「OIDC対応です」「デジタル認証サービスとOIDCで連携します」という説明を受ける機会が増えています。このとき、OpenID Connect(OIDC)というプロトコルが何を保証し、何を保証しないのかを押さえているかどうかで、仕様書やベンダー提案の読み方が変わります。本記事は、OIDCの仕様を「本人確認システムを作る人・発注する人」に必要な範囲で整理したものです。仕様確認日: 2026年8月23日。

対象読者は、「OIDCという単語は知っているが、IDトークンの中身や各パラメータが何を防いでいるのかまでは説明できない」という段階の開発者・発注担当者です。プロトコルそのものに絞って解説し、eKYCや犯収法上の本人確認との役割分担は後半でまとめます。

この記事の要点

OIDCはOAuth 2.0の上に「IDトークン」を載せた認証プロトコルで、「いま操作しているのは誰か」をサービス間で安全に受け渡す標準です

安全性の根幹は、IDトークンの検証（署名・iss・aud・exp・nonce）と、state・nonce・PKCEという3つの対策パラメータにあります

現在の標準は認可コードフロー+PKCEで、IDトークンはブラウザを経由せずサーバー間通信で受け取ります

デジタル認証サービスもGoogleログインも同じOIDCで会話できるため、仕様を一度押さえればIdPが変わっても実装の骨格は変わりません

OIDCが保証するのは当人認証であり、eKYC・犯収法の身元確認とは別物です。両者をつなぐ標準としてOIDC4IDAがあります

まずOAuth 2.0との違いから。認可と認証は別の仕事

OIDCを最短で理解するには、土台になっているOAuth 2.0との違いから入るのが近道です。

OAuth 2.0は「このアプリに、私のデータへのアクセスを許可する」ための認可（Authorization）の枠組みです。成果物はアクセストークン
OIDCは「いまログインしようとしているのは誰か」を伝える認証（Authentication）の枠組みです。成果物はIDトークン

両者の区別が重要なのは、過去に実際の事故があったからです。OAuth 2.0のアクセストークンは「何かにアクセスできる鍵」であり、「誰であるか」の証明ではありません。それでもアクセストークンだけを根拠に「ログイン成功」とみなす実装が広まった時期があり、他人のトークンを流用したなりすましを許すサービスが出ました。この穴を塞ぐために、「誰が・いつ・どの相手向けに認証されたか」を署名付きで表現するIDトークンをOAuth 2.0の上に追加した——これがOIDCの成り立ちです。

発注者の立場では、提案書に「OAuth認証」と書かれていたら注意信号です。OAuthは認可の仕組みであり、ログイン（認証）に使うならOIDCのIDトークンが必要、というのが仕様上の正しい整理だからです。用語の使い分けができているかは、ベンダーの理解度を測る簡単なリトマス試験紙になります。

3つの登場人物と、標準の認証フロー

OIDCに登場するのは次の3者です。

役割	仕様上の名前	例
ユーザー	End-User	ログインする本人
サービス側	RP（Relying Party）	自社のWebサービス・アプリ
認証を担う側	OP（OpenID Provider）	デジタル認証サービス、Google、Entra ID

自社サービスはRPとして、外部のOPに「この人を認証してください」と依頼する立場になります。現在の実装で標準とされるのは認可コードフロー（Authorization Code Flow）+ PKCEで、処理は次の5ステップで進みます。

RPがユーザーをOPの認証画面へリダイレクトします（このときstate・nonce・PKCEのcode_challengeを付与します）
ユーザーがOP側で認証します（パスワード、生体、マイナンバーカードなど。認証手段はOP側の設計次第です）
OPが「認可コード」を付けて、事前登録されたRPのredirect_uriへユーザーを戻します
RPがサーバー側からOPのトークンエンドポイントへ認可コードを渡し、IDトークンとアクセストークンを受け取ります
RPがIDトークンを検証し、問題がなければログインセッションを確立します

このフローの肝は、IDトークンがブラウザを経由せず、手順4のサーバー間通信で渡ることです。ブラウザに露出するのは使い捨ての認可コードだけで、これがコードフローが標準になった理由です。逆に、IDトークンをブラウザ経由で直接受け取るインプリシットフローは、現在は新規採用しない設計が推奨されています。既存システムの改修見積もりを取る際、インプリシットフローが残っていないかは確認しておきたいポイントです。

IDトークンの読み方。検証すべき6つのクレーム

IDトークンの実体はJWT（署名付きJSON）で、中身は「クレーム」と呼ばれるキーと値の集合です。次の6つを知っていれば、IDトークンはほぼ読めます。

クレーム	意味	検証で確認すること
iss	発行者（OPのURL）	想定したOPと完全一致するか
sub	ユーザーの識別子	OP内で一意・不変。アカウント紐付けのキーにする
aud	宛先（クライアントID）	自分宛てか。他RP向けトークンの流用を弾く
exp / iat	有効期限・発行時刻	期限切れ・未来の発行時刻を弾く
nonce	RPが最初に渡した乱数	自分が生成した値と一致するか。リプレイを弾く
auth_time / acr	認証時刻・認証強度	再認証の要求や認証手段の確認に使う

検証手順も仕様で決まっています。OPの公開鍵（JWKS）で署名を確かめたうえで、iss・aud・exp・nonceを順に照合します。どれか1つでも省略すると、それぞれに対応する攻撃——発行者偽装、他RP向けトークンの流用、期限切れトークンの再利用、リプレイ——が成立します。「検証はライブラリ任せ」で済ませる場合でも、そのライブラリがどのクレームまで検証しているかの確認は省けません。

もう1点、アカウント設計に直結するのがsubの払い出し方針です。subの発行方法はOPごと・クライアントごとに異なり、全RP共通の識別子を返すOPもあれば、RPごとに異なるペア識別子を返すOPもあります。ユーザーテーブルの主キー設計や、複数サービス間でのアカウント連携可否に影響するため、OPのドキュメントで最初に確認すべき項目です。

state・nonce・PKCE。似て見えて役割が違う3つの防御

認可コードフローには、乱数を使う似たようなパラメータが3つ登場します。混同されがちですが、防いでいる攻撃はそれぞれ別で、どれか1つでは代用になりません。

パラメータ	防ぐ攻撃	仕組み
state	CSRF（攻撃者が用意した認証結果を被害者のセッションに紐付ける）	リダイレクト前に乱数を発行し、戻ってきた値と照合する
nonce	IDトークンのリプレイ（盗んだトークンの再利用）	認証リクエストの乱数がIDトークン内に埋め込まれて返る
PKCE	認可コードの横取り（特にモバイルアプリのカスタムURLスキーム経由）	code_verifierを知るRPだけが認可コードをトークンに交換できる

PKCEはRFC 7636で定義された拡張仕様です。もともとはモバイルアプリ向けに作られましたが、現在はサーバーサイドWebアプリを含む全クライアントで使うことが推奨されています。デジタル庁のデジタル認証サービスもPKCEを必須としており、「PKCE対応の有無」は連携先IdPを問わず実装要件と考えるのが安全です。

DiscoveryとJWKS。エンドポイント設定を手書きしない理由

OPは自身の設定情報を /.well-known/openid-configuration というURLで公開しています。これがDiscoveryと呼ばれる仕組みで、認可・トークン・UserInfoの各エンドポイントURL、対応スコープ、署名アルゴリズム、そして公開鍵の置き場所（jwks_uri）がここに一覧されています。RP実装はこの情報を参照して構成するのが基本で、エンドポイントURLをコードに手書きで埋め込む設計は避けます。

運用で特に効いてくるのが署名鍵のローテーションです。OPは署名鍵を定期的に入れ替えるため、公開鍵を固定でコードに埋め込んでいると、ある日突然、全ユーザーがログインできなくなる障害につながります。正しい実装は、JWKSをkid（鍵ID）ベースで取得し、キャッシュしつつ、未知のkidが来たら再取得するという動作です。多くのライブラリが面倒を見てくれる部分ではありますが、「ログインが全滅した」という障害調査では必ず出てくる知識なので、運用引き継ぎ資料に含めておく価値があります。

scopeとUserInfo。「要求できる情報」と「実際に返る情報」

RPが受け取りたいユーザー情報は、scopeパラメータで要求します。openid は必須のスコープで、これがOAuthリクエストをOIDCリクエストに変えるスイッチの役割を果たします。加えて profile（氏名等）や email などの標準スコープがあり、属性情報はIDトークンまたはUserInfoエンドポイント経由で受け取ります。

ここで発注・契約の観点から重要なのは、仕様上要求できることと、実際に返ってくることは別だという点です。どの属性が返るかはOPの提供条件次第で、たとえばデジタル認証サービスでは、基本4情報（氏名・住所・生年月日・性別）の提供には署名APIの契約が必要で、認証APIの契約だけでは受け取れないという制約があります。「OIDCで属性が取れるはず」と仕様だけを見て要件を組むと、契約段階で計画が崩れます。マイナンバーカードを使った本人確認の方式ごとの違いはeKYCとJPKIの比較記事で、マイナンバーカード認証の導入支援の観点も含めて整理しています。

OIDCとeKYCの役割分担。当人認証と身元確認を混ぜない

本人確認システムの文脈では、OIDCの守備範囲を正確に把握しておく必要があります。

OIDCが保証するのは当人認証——いま操作しているのは登録済みの本人か
eKYC・犯収法の本人確認が扱うのは身元確認——この人は実在し、申告どおりの人物か

つまり、OIDCでログインできたことは、犯収法上の本人確認が完了したことを意味しません。この2つは要件定義で別項目として扱う必要があり、混ぜてしまうと監査・当局対応で問題になります。当人認証と身元確認の全体像はeKYC完全マップ2026で、2027年の犯収法改正後に使える確認手法は2027年以降のeKYC手法の整理でそれぞれ解説しています。

両者をつなぐ拡張仕様も存在します。OpenID Connect for Identity Assurance（OIDC4IDA）は、verified_claims というクレームに「どの証拠で・どの手法で・いつ確認した属性か」という検証メタデータを載せて運べる仕様で、身元確認の結果をOIDCの枠組みで流通させる標準です。eKYC基盤を自社で設計する、あるいは確認済み属性を複数サービスで使い回す構想があるなら、押さえておくべき仕様です。

RP実装チェックリスト。発注時の確認項目としても使える

RP実装で事故になりやすいポイントをチェックリストにまとめます。自社開発時のレビュー観点としても、外部ベンダーへの発注時に「この項目を満たすか」を確認する質問リストとしても使えます。ベンダー選定全般の確認項目はeKYC選定チェック20項目も参考にしてください。

redirect_uriはOP側に完全一致で登録し、ワイルドカードを使っていない
IDトークンの署名・iss・aud・exp・nonceをすべて検証している（ライブラリの検証範囲を確認済み）
stateはセッションに紐付けて保存し、使い捨てにしている
認可コードフロー+PKCEを採用し、インプリシットフローを新規採用していない
アクセストークン・IDトークンをログ・URL・localStorageに残していない
アカウントのキーはsubにしており、emailをキーにしていない（emailは変更・再割当てがあり得ます）
JWKSのkidローテーションに追従できる実装になっている

まとめ

OIDCはOAuth 2.0にIDトークンを追加した認証プロトコルです。認可（OAuth）と認証（OIDC）は別の仕事であり、アクセストークンだけでログインを実装してはいけません
標準は認可コードフロー+PKCEです。IDトークンはサーバー間通信で受け取り、署名とiss・aud・exp・nonceを必ず検証します
state・nonce・PKCEはそれぞれCSRF・リプレイ・認可コード横取りを防ぐ別々の防御で、全部使うのが前提です
エンドポイントと公開鍵はDiscoveryとJWKSで動的に取得し、コードへの手書き埋め込みを避けます
仕様上scopeで要求できる属性と、契約上実際に返る属性は別物です。デジタル認証サービスの基本4情報のように契約条件が絡むケースがあります
OIDCの当人認証とeKYCの身元確認は別物です。両者をつなぐ標準としてOIDC4IDAがあります

よくある質問

Q. OpenID ConnectとOAuth 2.0の違いは何ですか？

OAuth 2.0は「このアプリに私のデータへのアクセスを許可する」ための認可の仕組みで、成果物はアクセストークンです。OIDCはその上に構築された「いま操作しているのは誰か」を伝える認証の仕組みで、成果物はIDトークンです。アクセストークンは持ち主が誰かを証明しないため、ログイン機能にはOIDCのIDトークンが必要です。

Q. IDトークンとアクセストークンはどう違いますか？

アクセストークンは「リソースにアクセスできる鍵」で、IDトークンは「誰が・いつ・どの相手向けに認証されたかを署名付きで表した証明書」です。アクセストークンだけを根拠にログインを実装すると、他人のトークンを流用したなりすましを許した過去の事故と同じ穴を踏むことになります。

Q. state・nonce・PKCEは全部必要ですか？

全部必要です。stateはCSRF、nonceはIDトークンのリプレイ、PKCEは認可コードの横取りと、それぞれ防ぐ攻撃が異なり、どれか1つでは代用できません。PKCEはもともとモバイル向けの拡張（RFC 7636）でしたが、現在はサーバーサイドWebアプリを含む全クライアントで使うことが推奨されており、デジタル認証サービスでも必須とされています。

Q. インプリシットフローを使ってもいいですか？

新規採用は推奨されません。インプリシットフローはIDトークンをブラウザ経由で直接受け取るため、トークンがブラウザに露出します。現在の標準は、ブラウザには使い捨ての認可コードだけを通し、IDトークンをサーバー間通信で受け取る認可コードフロー+PKCEです。既存システムにインプリシットフローが残っている場合は、改修の検討対象になります。

Q. OIDCでログインできれば犯収法の本人確認になりますか？

なりません。OIDCが保証するのは当人認証（操作しているのが登録済みの本人であること）で、犯収法の本人確認が求める身元確認（実在し申告どおりの人物であること）とは別物です。身元確認の結果をOIDCの枠組みで運ぶにはOIDC4IDAという拡張仕様があり、verified_claimsクレームで確認済み属性とその検証方法を受け渡せます。

Q. デジタル認証サービスとGoogleログインは同じ実装で対応できますか？

プロトコルの骨格は同じです。どちらもOIDCのOPとして動作するため、認可コードフロー+PKCE、IDトークン検証、Discovery参照という実装の型は共通です。ただし、subの払い出し方針や、どの属性がどの契約で返るか（デジタル認証サービスでは基本4情報の提供に署名APIの契約が必要など）はOPごとに異なるため、個別の確認は必要です。

Q. OIDC実装を外注するとき、何を確認すればよいですか？

最低限、(1)認可コードフロー+PKCEを採用しているか、(2)IDトークンの署名・iss・aud・exp・nonceをすべて検証しているか、(3)redirect_uriを完全一致で登録しているか、(4)アカウントのキーにemailではなくsubを使っているか、(5)JWKSの鍵ローテーションに追従できるか、の5点を質問することをおすすめします。回答が曖昧なベンダーは、認証まわりの設計レビューを別途挟んだほうが安全です。

主な参考資料: OpenID Connect Core 1.0（仕様）、OpenID Connect Discovery 1.0、RFC 6749: The OAuth 2.0 Authorization Framework、RFC 7636: PKCE、OpenID Connect for Identity Assurance 1.0、デジタル庁デジタル認証サービス実装ガイド

TodoONadaでは、マイナンバーカード認証（JPKI・eKYC）を組み込んだWebサービス・スマホアプリの受託開発を行っています。OIDCによるデジタル認証サービス・各種IdPとの連携開発はもちろん、デジタル庁「デジタル認証アプリ」の利用申請・審査対応の伴走支援（書類作成から指摘対応まで）、犯収法など業種ごとの本人確認要件の整理からワンストップで対応します。料金の目安は認証機能組込みプラン150万円〜、認証込みアプリ開発プラン400万円〜です。認証基盤の設計レビューだけのご相談も承っていますので、マイナンバーシステム導入支援のページからお気軽にご連絡ください。

この記事に関連するサービス

TodoONada株式会社では、マイナンバーカード認証を組み込んだシステム開発を行っています。

マイナンバーシステム導入支援 — JPKI・eKYC対応の本人確認をワンストップで

導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。