メインコンテンツへスキップ
Diditが750万ドルを調達、本人確認と不正対策のインフラを構築
Didit
ブログ一覧へ
ブログ ・ 2026年10月6日

eID API連携ガイド：パターン、コード、セキュリティ

eID APIで各国のeIDを連携するための、コード中心のガイドです。リダイレクト、アプリプッシュ、QR、NFCカード、OpenID4VPの各フロー、自社で構築する部分、結果フィールド、フォールバック、セキュリティチェックリストを解説します。

By Didit更新日
eid-api-integration-guide-cover.png

要点

eID APIを使うと、サインアップ処理から国の電子ID（eID）スキームに本人認証を依頼し、署名付きの本人属性を受け取れます。どのスキームも次の5つのパターンのいずれかを使います。ブラウザリダイレクト、照合コード付きのアプリプッシュ、QRまたはアプリ起動、近距離無線通信（NFC）によるICカードの読み取り、OpenID for Verifiable Presentations（OpenID4VP）によるEUデジタルID（EUDI）ウォレットでの提示です。[2][6][8][14]

  • 署名と保証レベルは、引き続き自社で確認します。
  • ほとんどのスキームでは、最初の呼び出しの前に契約、証明書、または認定ブローカーが必要です。[12][13][15]

最終確認日：2026年10月5日 · 法的助言ではありません

このコード中心のガイドは、オンボーディングに国のeIDを追加するエンジニア向けです。

eID APIの仕組み：5つのインタラクションパターン

自社システムは依拠当事者（RP）です。認証情報そのものを見ることはなく、本人に関する署名付きの回答のみを受け取ります。

パターンユーザーの操作自社のバックエンドへの結果の届き方例
リダイレクト（OpenID Connect、OIDC）自社ページを離れてスキームのログイン画面でサインインし、戻ってくる認可コード。これを署名付きIDトークンと交換するID Austria。そのOIDCログインは認可コードフローのみに対応[6]
コード付きアプリプッシュ個人コードを入力し、画面上のコードをアプリの表示と照合し、アプリでPINを入力する署名付きの結果を待機またはポーリングするSmart-ID、Mobile-ID[10][20]
QRまたはアプリ起動パソコンでアニメーションQRを読み取る、または同じスマートフォンでアプリが起動するオーダーが完了するまでスキームにポーリングするBankID Sweden[8]
カードとNFCICカードをスマートフォンにかざし、カードのPINを入力するeIDサーバーがチップを読み取り、属性を返すドイツのeIDカード[14]
ウォレット提示（OpenID4VP）ウォレットアプリで共有する属性を承認する署名済みで選択的に開示された属性の提示EUDIウォレット[2]

一部のスキームは公開ゲートウェイの背後にあります。エストニアのTARAは、IDカード、Smart-ID、Mobile-ID、EUのeIDの前段に置かれた認可コード方式のゲートウェイです。[7] 各スキームがどのパターンを使うかは、国別のeIDスキームを参照してください。

自社で構築するものとプロバイダーが担うもの

コードより先にアクセスの確保が必要です。デンマークでは、すべてのサービス提供者が認定MitIDブローカーを経由しなければなりません。[12] スウェーデンでは、銀行または販売事業者からBankIDを購入し、依拠当事者証明書を発注します。[15] ドイツでは、自社でeIDサーバーを運用するか、自社の証明書でホスト型eIDサービスを利用するか、識別サービスを利用して自社では証明書を保有しないかのいずれかです。[13] EUDIウォレットについては、依拠当事者は設立先の加盟国で登録しなければなりません。[1]

レイヤースキームごとに直接接続1つのeID APIを経由
契約と証明書スキームごとに1つ。各スキームのサイクルで更新プロバイダーが保有。自社は契約1件のみ
プロトコルのコードOIDC、ポーリングAPI、eIDサーバー、OpenID4VP1つのセッションAPIと1つの結果形式
画面スキームごとの選択画面、QR、照合コード、エラーホスト型フローまたはSDK
署名検証自社で実施。スキームごとの鍵と形式プロバイダーが実施し、判定として報告
保証レベル要求と確認は自社で実施結果に記録。ポリシーは引き続き自社で設定
eIDを持たない人のための代替手段別のベンダーまたは手動の経路同じフロー内での本人確認書類ルート
オンボーディングの判断自社引き続き自社

認定ブローカーは北欧・バルト諸国の大半のスキームに存在します。1つのスキームを大量に扱う場合は直接接続し、ユーザーが複数の国から来る場合は1つのAPIを使います。

リダイレクトフローの手順

これはOIDCの認可コードフローです。自社のバックエンドはランダムなstateとnonceを付けてブラウザを外部へ送り出し、返ってきたコードをIDトークンと交換して検証します。

ユーザー 自社のバックエンド eIDプロバイダー
1登録を開始
2state、nonceを付けてリダイレクト

ユーザーがeIDでサインイン

3コールバックへコードを返却
4コードをトークンと交換
5署名付きIDトークン

state、nonce、署名、acrを検証

6口座開設

リダイレクト方式のサインインです。ブローカーやゲートウェイが入ると手順2の中継が増えますが、自社側の手順は増えません。

最も重要なのは手順5の後の検証です。DigdirのID-portenドキュメントによれば、クライアントは「セキュリティレベル（acr）が十分に高いことを検証しなければならない（MUST）」とされています。[5] acrはスキームが示す保証レベル（LoA）として読み取り、自社のポリシーを下回るものは拒否してください。

照合コードを使うアプリプッシュ方式

Smart-IDとMobile-IDでは、ユーザーは自社のページから離れません。ユーザーが個人識別コードを入力し（Mobile-IDでは電話番号も求められます）、ページに短いコードが表示され、同じコードがアプリにも表示されます。ユーザーはコードが一致した場合に限り、スマートフォンでPINを入力して承認します。[20] Smart-IDでは、3つのコードを表示して正しいものをユーザーに選ばせることもできます。[10]

本人確認

確認方法を選択

普段お使いの電子IDでサインインしてください。

Smart-ID

代わりに本人確認書類を使う

1ユーザーが、自社が受け付けるeIDの中から1つを選びます。

本人確認

コードを確認

4821

同じコードがSmart-IDアプリに表示されます。

2使用中の端末に表示された確認ページに照合コードが表示されます。同じコードがアプリにも表示されます。

Smart-ID

PINを入力

画面のコードと一致する場合のみ入力してください。

3ユーザーはPINをアプリで入力します。自社のページでは入力しません。

本人確認

本人確認が完了しました

  • 氏名共有
  • 生年月日共有
  • 個人コード共有
  • 住所非共有

4署名済みの属性が自社のバックエンドに届きます。

BankID Sweden も同じ形ですが、コードを入力する代わりにQRコードを使います。ユーザーは autostart token を使って同じ端末でアプリを開くか、別の端末に表示されるアニメーションQRコードを読み取ります。自社のバックエンドはオーダーが完了するまで /collect をポーリングします。完了したオーダーには、個人番号、氏名、名、姓に加え、端末、署名、任意のリスク項目が含まれます。[8] Smart-ID+ は Smart-ID をこのモデルに移行させます（デスクトップでは動的QRコード、モバイルではアプリ間連携）。そのため、ユーザーがウェブサイトで個人コードを入力する必要はなくなります。[11]

ユーザー 自社のバックエンド スキームのAPI スキームのアプリ
1個人コードを入力
2照合コードを表示
3認証リクエストを開始
4スマートフォンへプッシュ通知

アプリに同じコードが表示され、ユーザーがPINを入力します

5結果をポーリング
6署名済みの結果

Smart-ID または Mobile-ID でのサインインを、ユーザーに見える順に示しています。個人コード、自社ページ上の照合コード、アプリ内の同じコード、最後にPINです。[20] BankID のQRコード方式では、ステップ1がなくなり、ステップ2でQRコードが表示されます。

カードとNFC、そしてOpenID4VPによるEUDIウォレット

ドイツのeIDカードでは、ユーザーは AusweisApp を開き、NFC対応のスマートフォンにカードをかざします。PINを入力する前に、アプリは事業者の名称、住所、要求されたデータ項目を表示することが法律で義務付けられており、送信されるのはそのデータ項目だけです。[14]

OpenID Foundation によると、OpenID4VP 1.0 は最終仕様です。[16] アーキテクチャ・リファレンス・フレームワーク(ARF)は、リモート提示の方式として、リダイレクトと openid4vp:// などのカスタムURIスキームを用いるOpenID4VP、W3C Digital Credentials API を用いるOpenID4VP、または同APIを用いるISO/IEC 18013-7 を挙げています。[2][17] ウォレットは、何かを共有する前に、自社のアクセス証明書を認証し、登録した範囲を超える属性を要求していないかを確認し、ユーザーが属性ごとに承認できるようにします。[2] 本人識別データ(PID)で顔写真が必須になるのは2028年8月11日からで、ユーザーが明示的にオプトアウトした場合は除きます。[18]

  1. 2026年7月23日ARF v3.0.0ウォレットフレームワークの現行バージョン。
  2. 2026年12月24日ウォレットの提供期限各加盟国が少なくとも1つのウォレットを提供します。
  3. 2027年12月24日受け入れ法令または契約により強力なユーザー認証の使用を義務付けられた民間の依拠当事者は、ユーザーの求めに応じてこれを受け入れます。零細企業と小企業は適用除外です。
  4. 2028年8月11日顔写真ユーザーがオプトアウトしない限り、PIDの顔写真が必須になります。

eID APIのロードマップを左右するEUDIウォレットの日程。[1][2][18]

EUDIウォレットガイドでは、依拠当事者の登録と国別の準備状況を解説しています。

エラー、フォールバック、リトライ

サインインの結果は、完了、キャンセル、タイムアウト、失敗のいずれかです。後の3つは同じように扱い、その後の対応は国ごとに決めます。

1ユーザーの国のeIDを提示する

国ごとの許可リストから、ユーザーが選択します。

有効な署名と必要なレベルでサインインが完了した

はい

署名された属性を保存する

氏名、生年月日、識別子、保証レベル。

いいえ

代替手段に切り替えるか、拒否する

チップ読み取りによる本人確認書類の確認に切り替えるか、セッションを終了します。

2スクリーニングと判定

検証済みデータに自社のリスクルールを適用します。

キャンセルされたサインインを自動で再試行しないでください。コールバックは冪等にし、再読み込みや重複イベントで2つのアカウントが作成されないようにします。eIDを持たない人のための経路を残してください。通常は、NFCチップ読み取り、ライブネス検知、顔照合を組み合わせた本人確認書類による確認です。この経路についてはNFC eID検証とチップのセキュリティで解説しています。

eID API連携のセキュリティチェックリスト

  • サインインごとに新しいstateとnonceを生成し、一致しないコールバックは拒否します。
  • 属性を1つでも読み取る前に、すべてのトークンまたは結果の署名を検証します。
  • 保証レベルはリクエスト側だけでなく、結果側でも確認します。[5]
  • AMLRのeIDによる経路が適用される場合は、substantialまたはhighを要求します。[3]
  • eIDのPINを自社のページで収集しないでください。PINはスキームのアプリで入力するものです。[20]
  • クロスデバイスのサインインでは、コードの手入力よりもQRコードまたはアプリ間連携による起動を優先します。[11]
  • 登録済みで、かつ必要な属性だけを要求します。[1]
  • 結果を信頼する前に、Webhookの署名とタイムスタンプを検証します。

法的根拠はマネーロンダリング防止規則（AMLR）で、2027年7月10日から適用されます。第22条(6)(b)は「保証レベル『substantial』または『high』に関してRegulation (EU) No 910/2014の要件を満たす電子識別手段」を認めています。[3]すべてのスキームが通知済みというわけではありません。MitIDはEUの通知済みスキーム一覧に掲載されていますが、Smart-IDは掲載されていません。[4]

注意

ARFは、カスタムURIを使うクロスデバイスのフローは「フィッシング攻撃とリレー攻撃に対して脆弱」であると警告し、クロスデバイスの提示にカスタムURIスキームを推奨していません。[2]Computer Swedenによると、警察は2019年7月、QRコードの導入後にBankIDを悪用した電話詐欺が90%減少したと報告しました。[9]

Didit によるeID API連携の支援

Diditは、稼働中の5つのeID（MitID、BankID Sweden、Finnish Trust Network、Smart-ID、Mobile-ID、7か国）を1つのセッションAPIで提供し、同じワークフロー内に本人確認書類による経路も用意しています。その他のスキームはDiditのロードマップに含まれており、EUDIウォレットの受け入れは近日対応予定です。DiditがPINを求めることはありません。詳しくはデジタルIDウォレットのページとウォレットのドキュメントをご覧ください。[19]

国ごとに稼働中のeIDを有効にする

コンソールでは、Workflows、ID Verificationステップ、Countries、「Wallets accepted」の順に設定します。APIでは、ID Verification機能（OCR）が、ISO 3166-1 alpha-3国コードをキーとするmethodsオブジェクトを受け取り、POST /v3/workflows/で送信します。デンマーク向けのドキュメント記載例は次のとおりです。[21]

{ "feature": "OCR", "config": { "methods": { "DNK": { "document": { "enabled": true }, "wallet": { "enabled": true, "providers": ["mitid"], "on_failure": "fallback_to_document" } } } } }

エストニアで、電話ベースの両方のeIDを受け入れる場合は次のとおりです。[20]

{ "EST": { "document": { "enabled": true }, "wallet": { "enabled": true, "providers": ["smart_id", "mobile_id"], "on_failure": "fallback_to_document" } } }

providersは受け入れリストであり、優先順位ではありません。on_failureはfallback_to_documentまたはdeclineです。利用環境で使えないウォレットを指定すると保存全体が拒否されるため、先にカタログを確認してください。[21]

スクリーンショット準備中：console-wallets-accepted

Didit コンソールで、1つの国について受け付ける eID を選択する画面。

セッションを作成し、結果を読み取る

workflow_id(任意で vendor_data と callback)を指定して POST /v3/session/ を呼び出すと、session_id、url、session_token が返されます。URL を開くか、SDK を使用します。[24] 結果は Webhook または GET /v3/session/{id}/decision/ で届きます。結果には verification_method: "wallet"、assurance: "cryptographic" と wallet_verification オブジェクトが含まれます。[19]

フィールド例示す内容
providermitidユーザーが選択した eID
issuing_authorityDanish Agency for Digital Government本人情報を保証する主体
issuing_countryDNK本人確認の経路を示します。国籍ではありません
level_of_assurancesubstantialスキームが表明したレベル
signature_validtrue署名付きアサーションの検証に成功したこと
attributesfull_name、date_of_birth、cpr_alias検証済みのクレーム。名称は eID ごとに異なります
portrait、face_match_scorenull顔写真を共有する稼働中の eID はありません

要求したレベルより低いレベルの場合、サインインは失敗となります。課金対象は完了したサインインのみです。[19] 料金：MitID、Finnish Trust Network は $0.25、BankID Sweden、Smart-ID、Mobile-ID は $0.20 です。

Webhook とサンドボックス

X-Signature-V2 を送信先のシークレットで検証し、300 秒より古い X-Timestamp は拒否し、冪等性のキーには event_id を使用してください。配信に失敗した場合、最大 2 回まで再試行されます。[22] サンドボックスのアプリケーションではすべてのウォレットを有効にできます。実際のサインインなしで承認され、フォールバックをテストするために wallet_cancelled、wallet_timeout、wallet_provider_error を利用できます。[23]

eID対象国Didit レベルDidit ステータス
MitIDデンマークSubstantial提供中
BankID SwedenスウェーデンSubstantial提供中
Finnish Trust NetworkフィンランドSubstantial提供中
Smart-IDエストニア、ラトビア、リトアニア、ベルギー高提供中
Mobile-IDエストニア、リトアニア高提供中
BankID Norwayノルウェー未設定近日対応予定
Freja eIDスウェーデン未設定近日対応予定
itsmeベルギー未設定近日対応予定
iDINオランダ未設定近日対応予定
ドイツのeIDカードドイツ未設定近日対応予定
FranceConnectフランス未設定近日対応予定
ID Austriaオーストリア未設定リクエストに応じて対応
Cl@veスペイン未設定リクエストに応じて対応
SPIDイタリア未設定リクエストに応じて対応
Swiss E-IDスイス未設定リクエストに応じて対応
EUDIウォレットEUおよびEEA未設定近日対応予定

Diditが提供するもの

  • スキームへのアクセス、証明書、署名検証
  • 単一のセッションAPI、ホスト型フロー、SDK
  • eIDを持たない利用者向けの、NFCチップ読み取りによる本人確認書類ルート

貴社に残るもの

  • 各国でどのeIDを受け入れるか
  • 貴社のポリシーが求める保証レベル
  • オンボーディングの判断と責任

対象とするすべての国に対応する1つのeID API

国ごとに稼働中のeIDを有効にし、本人確認書類をフォールバックとして残し、完了したサインインに対してのみ支払います。

無料で始めるお問い合わせドキュメントを読む

要点

  • すべてのeIDは、リダイレクト、コード付きのアプリプッシュ、QRまたはアプリ起動、カードとNFC、OpenID4VPの5つのパターンのいずれかを使います。
  • まずアクセスの確保です。ブローカー、契約、証明書、または登録が必要です。
  • すべての結果について、署名と保証レベルを検証してください。
  • 法令または契約により強固なユーザー認証の使用が求められる民間の依拠当事者は、2027年12月24日までに、利用者の求めに応じてEUDIウォレットを受け入れなければなりません（零細企業および小規模企業は適用除外です）。

よくある質問

eID APIとは何ですか。

アプリケーションが国の電子IDスキーム、または複数のスキームに接続するプロバイダーに対し、本人を認証して署名付きの本人属性を返すよう要求できるインターフェースです。その応答の署名と保証レベルは、引き続き貴社が検証します。

eIDスキームごとに個別の統合が必要ですか。

直接接続する場合は必要です。スキームごとに独自の契約、証明書、プロトコルがあります。デンマークでは認定MitIDブローカーを使う必要があり、スウェーデンのBankIDは銀行または販売事業者から購入します。[12][15] 単一のeID APIなら、こうした違いを1つのセッションと1つの結果形式の背後に隠せます。

国のeIDはどのプロトコルを使いますか。

多くのスキームはOpenID Connectを使っており、ID-portenやTARAなどのゲートウェイを経由することがよくあります。[5][7] 独自のポーリング型APIを使うスキーム (BankID Sweden、Smart-ID) や、ICカードを読み取るeIDサーバーを使うスキーム (ドイツ) もあります。[8][13] EUDIウォレットはOpenID4VPまたはISO/IEC 18013-7を使います。[2]

eIDによるサインインではどのようなデータが返されますか。

スキームによって異なります。BankID Swedenは個人番号、氏名、名、姓を返します。[8] ドイツのeIDカードは、事業者の証明書に記載されたデータ項目のみを送信します (§ 18(5))。カードの国民ID番号は§ 18(3)のリストに含まれていないため、送信されません。[14]

保証レベルはどのように徹底すればよいですか。

必要なレベルを要求し、結果で示されたレベルを確認します。OIDCのacrクレームなどがこれにあたります。ID-portenは、クライアントはセキュリティレベルが十分に高いことを検証しなければならないとしています。[5] 自社のポリシーを下回るものはすべて不十分として扱い、口座を開設しないでください。

ユーザーがeIDを持っていない場合や、キャンセルした場合はどうすべきですか。

代替手段を用意するか拒否するかを国ごとに決めてください。キャンセルされたサインインを自動で再試行しないでください。

実際のユーザーを使わずにeID連携をテストするにはどうすればよいですか。

プロバイダーのサンドボックスで、承認、キャンセル、タイムアウトをシミュレーションします。シミュレーション上の承認は、実際の本人がサインインできることを証明するものではありません。導入前に、許可を得た実機テストを実施してください。[20]

事業者はいつまでにEUDIウォレットを受け入れなければなりませんか。

法令または契約により強固なユーザー認証の使用を義務付けられている民間の依拠当事者は、2027年12月24日までに、ユーザーの求めに応じてEUDIウォレットを受け入れなければなりません。零細企業と小規模企業は適用除外です。[1]

出典

  1. Regulation (EU) 2024/1183 (eIDAS 2)、EUR-Lex、2024年4月30日付EU官報、第5a条、第5b条、第5f条。
  2. Architecture and Reference Framework v3.0.0、欧州委員会EUDIウォレットプロジェクト、2026年7月23日公開、セクション4.4.3、5.7.1、6.6.3。
  3. Regulation (EU) 2024/1624 (AMLR)、EUR-Lex、第22(6)条。
  4. Overview of pre-notified and notified eID schemes under eIDAS、欧州委員会、2026年10月5日閲覧。
  5. ID-porten ID token、ノルウェー・デジタル化庁 (Digdir)。
  6. Anbindung mit OpenID Connect、ID Austria開発者向けドキュメント。
  7. TARA technical specification、エストニア情報システム庁 (RIA)。
  8. Auth and sign: collect、BankID開発者向けドキュメント。
  9. QR-koden gjorde susen: BankID-bedrägerierna ned med 90 procent、Computer Sweden、2019年7月3日 (二次資料)。
  10. Why do I sometimes see one confirmation code and sometimes three、Smart-ID。
  11. How does the new Smart-ID protect me from fraud、Smart-ID。
  12. MitID brokers、デンマーク・デジタル政府庁。
  13. Become a service provider、AusweisApp、ドイツ連邦政府。
  14. 旅券・身分証明書法 (PAuswG) 第18条、Gesetze im Internet。
  15. Connect your business to BankID、BankID。
  16. OpenID for Verifiable Presentations 1.0 final specification approved、OpenID Foundation。
  17. Digital Credentials、W3C。
  18. Commission Implementing Regulation (EU) 2026/1731、EUR-Lex、2028年8月11日以降のPIDにおける顔写真。
  19. デジタルIDウォレット、Didit ドキュメント。
  20. Smart-ID と Mobile-ID の連携、Didit ドキュメント。
  21. ワークフローの機能設定、Didit ドキュメント。
  22. Webhook、Didit ドキュメント。
  23. サンドボックスとテストデータ、Didit ドキュメント。
  24. クイックスタート、Didit ドキュメント。

このシリーズの他の記事

各国のeID、その保証レベルとステータスはeID認証ページでご確認ください。

スキームごとの契約なしでeIDサインインを導入

まずは提供中のeIDから始め、ユーザーのニーズに応じてスキームを追加し、それ以外のユーザーには本人確認書類を引き続き利用できます。

無料で始めるお問い合わせ

続きを読む

関連記事

本人確認と不正対策のインフラ。

KYC、KYB、取引監視、ウォレットスクリーニングを一つのAPIで。5分で統合できます。

無料で始めるお問い合わせ
AIにこのページの要約を依頼する