OpenID Connectとマイナンバーカード認証の関係。カードを直接読む方式とIdP連携方式を整理する

Q: マイナンバーカード認証の接続モデルにはどんな種類がありますか？

3つあります。JPKI直接方式（自社またはSDKでカード読み取りを実装し、OIDCは登場せず生のPKI検証）、デジタル認証アプリ方式（デジタル庁アプリがカード読み取りを担い、事業者はOIDCのRPを実装）、プラットフォーム事業者経由（事業者のSDK/APIが担い、OIDCの有無は事業者により異なる）です。

Q: 本人確認（eKYC）までやる場合、OpenID Connectで完結しますか？

完結しません。本人確認まで踏み込む場合、OIDCの拡張仕様であるOpenID Connect for Identity Assuranceが関わり、日本ではOpenIDファウンデーション・ジャパンのKYCワーキンググループによる「民間事業者向けデジタル本人確認ガイドライン」が保証レベルと情報授受を整理しています。署名APIを使う場合はプラットフォーム事業者との契約・届出というOIDC外の要素も入ります。

「マイナンバーカード認証をOpenID Connectで実装したい」という相談が増えています。ただ、この2つの関係は整理が必要です。結論から言うと、マイナンバーカードそのものはOpenID Connect（OIDC）ではありません。公開鍵基盤（PKI）です。 両者をつないでいるのが、デジタル庁が2024年6月に提供を開始したデジタル認証アプリで、これがマイナンバーカードをOIDCのIdP（認証を担う側）に変えました。

この違いは技術的な言葉遊びではなく、どの方式を選ぶかで自社の開発範囲・契約先・工数配分がまるごと変わるという設計判断に直結します。本記事では、開発責任者がRP（サービス側）として実装するときに知っておくべき「カードを直接読む世界」と「OIDCで認証結果を受け取る世界」の関係を整理します。確認日: 2026年7月6日。

更新（2026年8月23日）: 本文中の「デジタル認証アプリ」はサービス名称が「デジタル認証サービス」へ変わり、利用者が使うスマホアプリは2026年8月25日に新アプリ「マイナアプリ」へ統合される予定です。変更点はデジタル認証サービスへ名称変更。顔写真提供も始まるにまとめています。以下の本文の名称は執筆時点（2026年7月）のものです。

この記事の要点

マイナンバーカードはPKI（公的個人認証／JPKI）であり、OpenID Connectそのものではありません

デジタル認証アプリが、マイナンバーカードのPKIをOIDCのIdPへ橋渡しします。事業者は標準的なRPを実装すればよくなります

接続モデルは3つ（JPKI直接方式／デジタル認証アプリ方式／プラットフォーム事業者経由）で、OIDCが登場するかは方式で変わります

仕様は認可コードフロー・ES256・private_key_jwt・PKCEといった標準の組み合わせで、デジタル庁独自のプロトコルではありません

本人確認まで踏み込むならOpenID Connect for Identity Assuranceとガイドラインが関わります。認証か本人確認かを最初に切り分けてください

前提の確認。マイナンバーカードはPKIであってOIDCではない

マイナンバーカードのICチップには、電子証明書と秘密鍵が格納されています。認証は次の流れで成立します。

利用者がスマートフォンやカードリーダーでICチップを読み取り、暗証番号を入力する
カードが秘密鍵で署名し、対になる電子証明書を提示する
検証側が署名を確認し、証明書の有効性をJ-LIS（地方公共団体情報システム機構）に問い合わせる

これは公開鍵暗号による署名・検証の仕組みで、**公的個人認証（JPKI）**と呼ばれます。ここにOIDCは一切登場しません。トークンもリダイレクトもなく、あるのは署名と証明書と失効確認だけです。

証明書には署名用と利用者証明用の2種類があり、どちらを使うかで開発の中身が変わります。この使い分けは署名用電子証明書と利用者証明用電子証明書の違いで扱っています。

この前提を最初に共有しておくことには実務的な意味があります。社内で「OIDCで実装する」という言葉だけが先行すると、JPKI直接方式を選んだ場合にOIDCが出てこないことに気づかないまま設計が進みます。 方式が決まる前の段階では「OIDCで」ではなく「どの接続モデルで」という言い方に統一するのが安全です。

OpenID Connectとは何か（最短の説明）

OIDCは、OAuth 2.0という認可の仕組みの上に「本人が誰か」を伝えるID層を乗せた標準仕様です。登場人物は2つだけです。

IdP（Identity Provider）: 利用者を認証し、結果をIDトークンとして発行する側
RP（Relying Party）: IdPの認証結果を受け取って自サービスにログインさせる側

RPは、利用者をIdPにリダイレクトし、認証後にIDトークン（利用者情報が入った署名付きのJWT）を受け取って検証します。「Googleでログイン」を実装したことがあれば、そのGoogleがIdP、自サービスがRPです。

ここで重要なのは、RPはIdPが内部でどう認証したかを気にしなくてよいという点です。パスワードでも生体認証でも、RPが受け取るのは標準化されたIDトークンだけ。この抽象化があるからこそ、「マイナンバーカードで認証する」という特殊な処理をIdP側に閉じ込められます。OIDCの仕様そのものをもう少し詳しく押さえたい場合はOpenID Connect仕様の基礎を参照してください。

マイナンバーカード認証の3つの接続モデル

マイナンバーカード認証をサービスに組み込むとき、OIDCが関わるかどうかは方式で変わります。

接続モデル	カード読み取りの実装	OIDCの登場	主な担い手
JPKI直接方式	自社またはSDKで実装	なし（生のPKI検証）	eKYCベンダー、プラットフォーム事業者
デジタル認証アプリ方式	デジタル庁アプリが担う	あり（RP実装）	デジタル庁＋自社
プラットフォーム事業者経由	事業者のSDK/APIが担う	事業者により異なる	認定プラットフォーム事業者

JPKI直接方式では、事業者はカード読み取り・署名検証・失効確認を自前（またはベンダーのSDK）で扱います。OIDCは出てきません。カード読み取りUXを自社で完全に統制できる代わりに、NFCの実装検証・証明書検証・J-LISへの失効確認まわりの負荷を自社側で抱えることになります。

デジタル認証アプリ方式では、カードを読むのはデジタル庁のアプリで、事業者はその認証結果をOIDCのRPとして受け取ります。つまりデジタル認証アプリは、マイナンバーカードのPKIをOIDCに橋渡しするIdPとして機能します。

プラットフォーム事業者経由の場合、OIDCが関わるかは事業者の提供形態によって変わります。SDK型なのかAPI型なのか画面ホスト型なのかで、自社の実装範囲もOIDCの有無も変わるため、比較時には必ず確認してください。プラットフォーム事業者を使うか自社で認定を取るかという論点は公的個人認証（JPKI）の民間利用とJPKIのPF方式とSP方式で扱っています。

JPKI直接方式とデジタル認証アプリ方式の違いを示す図

デジタル認証アプリ＝マイナンバーカードをIdPにする仕組み

デジタル認証アプリと連携する事業者は、標準的なOIDCのRPを実装します。デジタル庁の仕様は次のようになっています。

項目	仕様
フロー	認可コードフロー（OAuth 2.0 / OpenID Connect Core 1.0）
IDトークンの署名アルゴリズム	ES256（ECDSA + SHA-256）
クライアント認証	private_key_jwt（RFC 7523。クライアントシークレットではなく秘密鍵で認証）
認可コード横取り対策	PKCE（RFC 7636）
署名APIを使う場合	RP側で署名対象データをSHA-256でハッシュ化し、DigestInfoを付与してbase64化したうえで署名トランザクション開始を要求する

利用者はデジタル認証アプリでマイナンバーカードを読み取り、事業者（RP）はIDトークンで認証結果を受け取ります。事業者側にカード読み取りやJ-LIS問い合わせの実装は不要になります。 これが方式選定でいちばん大きな差です。

なおクライアント認証がprivate_key_jwtである点は、実装計画に影響します。クライアントシークレットを環境変数に置くだけでは済まず、秘密鍵の生成・保管・ローテーションの運用設計が必要になるためです。鍵管理の方式（KMSを使うのか、どこに置くのか、誰が更新するのか）は、要件定義の段階でインフラ担当と握っておくべき項目です。

この連携開発の実務（申請フロー・費用・工数）はデジタル認証アプリ連携の開発実務に詳しくまとめています。

開発者が引っかかる勘所

OIDCのRP実装経験があってもハマりやすい点があります。ベンダー選定時に、これらへの理解度を確認する質問として使うこともできます。

Public Clientの扱い。 SPAやネイティブアプリ単体で使ってよいか、という論点です。実務ではバックエンドと組み合わせてConfidential Clientとして扱う構成が無難です。

IDトークン検証の省略をしないこと。 ES256の署名検証に加え、nonce・aud・iss・有効期限の検証を省略しないでください。IdPが国であっても、検証手順は標準どおりに実装します。「相手が国だから安全」という理由で検証を省くのは、OIDCの設計思想に反します。

参照すべき標準。 OpenID Connect Core 1.0、RFC 6749（認可コードフロー）、RFC 7515（JWS）、RFC 7517（JWK）、RFC 7519（JWT）、RFC 7636（PKCE）、RFC 7523（クライアント認証）。デジタル庁独自の仕様ではなく標準の組み合わせなので、既存のライブラリがそのまま使えます。見積もりで「独自仕様への対応」を理由に大きな工数が積まれている場合は、根拠を確認する価値があります。

非対応ユーザーの受け皿。 カード未取得・アプリ非導入の利用者に対する代替フローは、IdP側では解決されません。RP側の設計範囲として残ります。

技術的なコア（OIDC接続）よりも、代替フロー設計と既存会員基盤との突合のほうに工数が積まれるのは、他のソーシャルログイン連携と同じ構図です。「OIDCなら簡単でしょう」という前提で見積もりを圧縮すると、後半で破綻します。

本人確認（eKYC）とOIDCの関係

ログイン（当人認証）ではなく、口座開設のような本人確認まで踏み込む場合、OIDCの拡張仕様であるOpenID Connect for Identity Assurance（本人確認済み情報の受け渡しを標準化した仕様）が関わってきます。

日本では、一般社団法人OpenIDファウンデーション・ジャパンのKYCワーキンググループが「民間事業者向けデジタル本人確認ガイドライン」を公表しており、本人確認の保証レベルとOIDCでの情報授受を整理しています。

実務上ここで押さえるべきは、認証で足りるのか本人確認まで必要かで、使うAPI（認証APIか署名APIか）も設計も契約も変わるという点です。犯収法対応を考えるうえで最初に切り分けるべきところで、ここが曖昧なまま開発を始めると、要件定義の途中で方式ごとやり直しになります。本人確認方式の全体像はeKYC完全マップ2026で俯瞰できます。

どちらを選ぶか

目的から逆算すると、選択はかなり絞り込めます。

目的	推奨される方式	理由
ログイン強化・当人認証	デジタル認証アプリ（OIDC・認証APIは無料）	標準的なRP実装で済み、カード読み取りを自社で持たなくてよい
犯収法対応の本人確認	署名APIやeKYCベンダーとの比較が必要	OIDCで完結しない要素（プラットフォーム事業者契約・届出）が入る
カード読み取りのUXを細かく作り込みたい／OIDCを挟みたくない	JPKI直接方式、またはプラットフォーム事業者との直接契約	UXの統制と引き換えに実装・運用範囲が広がる

選択肢全体の比較と費用感はマイナンバーカード本人確認を自社サービスに組み込む方法は4つにまとめています。

方式選定チェックリスト

目的は当人認証（ログイン）か、身元確認（犯収法等の本人確認）か
氏名・住所などの基本4情報を自社に取り込む必要があるか
カード読み取りのUXを自社で統制する必要が本当にあるか（あるならJPKI直接方式が候補）
既存のID基盤にOIDCのIdPを追加できる構成か
private_key_jwtの秘密鍵をどこで生成・保管し、誰がローテーションするかを決めたか
IDトークン検証（署名・nonce・aud・iss・有効期限）を実装項目として明記したか
カード未取得・アプリ非導入ユーザーの代替フローを仕様化したか
認証結果と既存会員基盤の突合ルール（初回連携・複数アカウント・退会）を決めたか
本人確認まで踏み込む場合、保証レベルとガイドラインへの適合を確認したか

まとめ

マイナンバーカードそのものはPKI（公的個人認証／JPKI）であり、OpenID Connectではありません
デジタル認証アプリが、マイナンバーカードのPKIをOIDCのIdPへ橋渡しします。事業者は標準的なRPを実装すればよくなります
仕様は認可コードフロー・ES256・private_key_jwt・PKCEといった標準の組み合わせで、独自仕様ではありません。既存ライブラリが使えます
カードを直接読むJPKI直接方式ではOIDCは登場しません。方式によってOIDCが関わるかが変わるため、「OIDCで実装する」という言葉が先行しないよう注意してください
本人確認まで踏み込むならOpenID Connect for Identity Assuranceとガイドラインが関わります。認証か本人確認かを最初に切り分けてください
工数はOIDC接続そのものより、代替フロー設計と既存会員基盤との突合に積まれます

よくある質問

Q. マイナンバーカード認証はOpenID Connectですか？

マイナンバーカードそのものはOpenID Connectではなく、公開鍵基盤（PKI）です。ICチップの電子証明書と秘密鍵を使い、署名・検証と証明書の有効性確認（J-LISへの照会）で成立する仕組みで、これを公的個人認証（JPKI）と呼びます。OIDCが関わるのは、デジタル庁のデジタル認証アプリを経由する方式を選んだ場合です。

Q. デジタル認証アプリはIdPなのですか？

はい、マイナンバーカードのPKIをOIDCに橋渡しするIdPとして機能します。利用者はデジタル認証アプリでマイナンバーカードを読み取り、事業者はRP（Relying Party）としてIDトークンで認証結果を受け取ります。事業者側にカード読み取りやJ-LISへの問い合わせの実装は不要になります。

Q. マイナンバーカード認証の接続モデルにはどんな種類がありますか？

3つあります。JPKI直接方式（自社またはSDKでカード読み取りを実装。OIDCは登場せず生のPKI検証）、デジタル認証アプリ方式（デジタル庁アプリがカード読み取りを担い、事業者はOIDCのRPを実装）、プラットフォーム事業者経由（事業者のSDK/APIが担い、OIDCの有無は事業者により異なる）です。

Q. デジタル認証アプリのOIDC仕様は独自仕様ですか？

独自仕様ではありません。認可コードフロー（OAuth 2.0 / OpenID Connect Core 1.0）、IDトークン署名はES256（ECDSA + SHA-256）、クライアント認証はprivate_key_jwt（RFC 7523）、認可コード横取り対策にPKCE（RFC 7636）という標準仕様の組み合わせです。OpenID Connect Core 1.0やRFC 6749・7515・7517・7519などを参照すればよく、既存のライブラリが使えます。

Q. デジタル認証アプリのRP実装でハマりやすいのはどこですか？

主に4点です。Public Clientの扱い（実務ではバックエンドと組み合わせConfidential Clientとするのが無難）、IDトークン検証（ES256の署名検証に加えnonce・aud・iss・有効期限の検証を省略しない）、参照すべき標準仕様の把握、そしてカード未取得・アプリ非導入ユーザーの代替フロー設計です。最後の代替フローはIdP側では解決されず、RP側の設計範囲として残ります。

Q. 本人確認（eKYC）までやる場合、OIDCで完結しますか？

完結しません。口座開設のような本人確認まで踏み込む場合、OIDCの拡張仕様であるOpenID Connect for Identity Assuranceが関わり、日本ではOpenIDファウンデーション・ジャパンのKYCワーキンググループによる「民間事業者向けデジタル本人確認ガイドライン」が保証レベルと情報授受を整理しています。また署名APIを使う場合はプラットフォーム事業者との契約・届出というOIDC外の要素も入ります。

Q. JPKI直接方式とデジタル認証アプリ方式はどう選べばよいですか？

目的で決まります。ログイン強化・当人認証が目的なら、認証APIが無料で標準的なRP実装で済むデジタル認証アプリ方式が第一候補です。犯収法対応の本人確認が目的なら、署名APIやeKYCベンダーとの比較が必要になります。カード読み取りのUXを細かく作り込みたい、あるいはOIDCを挟みたくない場合は、JPKI直接方式やプラットフォーム事業者との直接契約が選択肢になります。

主な参考資料: デジタル庁開発者サイト実装ガイドライン、デジタル庁 APIリファレンス（民間事業者向け）、OpenIDファウンデーション・ジャパン民間事業者向けデジタル本人確認ガイドライン、デジタル認証アプリとのID連携で使われている標準化仕様と勘所（ritou）

TodoONada株式会社では、デジタル認証アプリ連携（OpenID Connect）やJPKI直接方式を含むマイナンバーカード認証・電子署名の組み込み開発を受託しています。「認証で足りるのか本人確認まで必要か」「OIDC連携と直接読み取りのどちらが自社に合うか」という方式選定の段階からご相談いただけますし、デジタル庁「デジタル認証アプリ（デジタル認証サービス）」の利用申請・審査対応も書類作成から指摘対応まで伴走します。料金の目安は認証機能組込みプラン150万円〜、認証込みアプリ開発プラン400万円〜、大規模・個別要件は1,000万円〜です。関連記事の読み進め方はeKYC記事ガイドにまとめています。ご相談はマイナンバーシステム導入支援またはお問い合わせからお気軽にどうぞ。

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

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

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

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