民間事業者がマイナンバーカードの「デジタル認証アプリ」認証APIを使うには — 無料・契約ベースの申込フロー

マイナンバーカードの本人確認を自社サービスに組み込みたいとき、デジタル庁の「デジタル認証アプリ」の認証APIが使えます。実際に民間事業者として申し込もうとして調べた、利用条件・申込フロー・技術仕様をまとめます(自分の備忘も兼ねて)。

デジタル認証アプリとは

マイナンバーカードを使った認証・署名を、安全に簡単にするためのデジタル庁提供のアプリ。民間事業者は連携APIを使って、本人確認・認証(認証API)や電子署名(署名API)を自社サービスに組み込めます。認証・署名のプロセスは OAuth 2.0 / OpenID Connect の認可コードフローに基づきます。

費用と対象

  • 費用:無料(認証API・署名APIとも)。
  • 対象:行政機関 + 民間事業者。ただし後述のとおり契約ベースのオンボーディングなので、事業者(法人等)を前提にした枠組み。

申込フロー(自己サーブの開発者キーではない)

「数分でAPIキー発行」ではなく、デジタル庁との契約手続きです。流れは:

① 問合せ(フォーム)
② 利用申込
③ 事前準備契約の締結  ← テスト環境を使うのにこれが必要
④ テスト環境の提供・テスト
⑤ 本契約の締結
⑥ 本番環境の提供・テスト

入口は サポートサイトの「リクエストを送信」フォーム(support.aas.digital.go.jp/hc/ja/requests/new)。「【民間事業者・行政機関】デジタル認証アプリサービスAPI導入に関するお問合せ」を選び、事業者名・法人番号・担当者・サービス名/内容・想定トランザクション数などを入力します。

提出物・準備するもの

  • 申込書・サービス基本情報(サービス名/内容/取扱情報/redirect_uri)・誓約体制/責任者情報
  • 法人番号、連絡先(代表/窓口)
  • 技術:private_key_jwt 用の鍵(JWKS 登録)、暗号化用公開鍵(サービス単位・テスト/本番別)

「体制」は人数ではなく責任の所在が問われます。一人法人でも、代表が責任者・窓口を兼ね、鍵・認証情報を適切に管理する旨を示せれば筋は通ります。

技術仕様の勘所

  • 認可コードフロー + PKCE、クライアント認証は private_key_jwt(JWKS 登録)。
  • IdP は Keycloak ベース(エンドポイントは auth-and-sign.go.jp/.../realms/main/...)。OIDC discovery で取得可能。
  • 「暗号化用公開鍵を登録」とあるので、id_token / userinfo が JWE 暗号化される可能性が高い(署名検証の前に自鍵で復号が要る)。
  • RPは aud = 自分の client_id を検証。sub はユーザー識別子。RP単位での固有性・安定性、カード再発行時の挙動は実装ガイド/テスト環境で要確認。

まとめ

無料で強力だが、契約ベースで事業者前提。テスト環境までに事前準備契約が要る点が、軽い技術検証との一番の段差です。逆に言えば、法人で責任体制を示せれば、マイナによる本人確認を無料で組み込める。実装側は OIDC discovery + private_key_jwt +(必要なら)JWE 復号を用意しておけば、テスト client_id が出た後の差し替えがスムーズです。

(参照:デジタル庁 開発者サイト developers.digital.go.jp / 実装ガイドライン・APIリファレンス)

コメント

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

IP: 取得中...
216.73.216.103216.73.216.103