デジタル認証アプリとのID連携で使われている標準化仕様と勘所
ritou です。
みんなが待っていたデジタル認証アプリの情報が公開されました。
開発者向けのガイドライン、APIリファレンスなどのドキュメントも公開されています。
今回は開発者視点でどんな作りになっていて、利用するために理解が必要となる標準化仕様はどのあたりなのかを取り上げます。ちょっとOIDCのRPやOAuthのClient実装経験のある開発者向け、ぐらいの内容です。
概要
公開された情報からすると
-
デジタル認証アプリサービス(アプリ+バックエンド)はマイナンバーカードを用いた当人認証を実施
- 現在は都度マイナンバーカードを利用する必要がありますが、いずれはスマホに保存されたカード情報を使ってもっと楽になりそう
-
ID連携のIdentityプロバイダとして認証イベント情報、基本4情報といった属性情報を民間/行政サービスに提供
- 民間/行政サービスは認証イベント情報に含まれるユーザー識別子を利用して当人認証を実現可能
- 民間/行政サービスは4情報を利用して身元確認が可能
- さらに署名機能も提供するよ
という感じです。署名のところは一旦置いておきます。
まず、このデジタル認証アプリが出ますよーと言う記事を見て何度も感じていた "お前らが言う本人確認 is 何？" については、身元確認 と 当人認証 の両方が可能です。
そして、それら両方を実現するためのID連携として、OpenID Connect(以下、OIDC)が採用されています。SAMLaiではなく我々のターンです。
まずは挙動を理解しやすくするために認証フローを見てみましょう。
認証フローの確認
次の資料に認証フローが書いてあります。
スマートフォンから認証を始める場合
同一スマホ内で完結するパターンです。
- 民間/行政サービスからデジタル認証アプリを立ち上げる : 「本人確認」って表現は微妙
- デジタル認証アプリ上でローカル認証 : これの目的は、アプリへ安全にログインするためとあります
- 認証手順を確認する : 説明大事！（ただし、慣れたり形骸化するのでスキップするチェックボックスがほしいかも)
- 利用者証明用電子証明書の暗証番号の入力 : 当人認証 のために必要
- 【一部サービスのみ】券面事項入力補助用の暗証番号の入力 : 身元確認の目的で属性情報として４情報が要求されている場合は必要
- マイナンバーカードの読み取り
- サービスへの認証を許可 : OIDCの同意画面
- 認証が完了 : ボタンをクリックして戻る
4,5,6でマイナンバー関連の処理、7がOIDCの認証フローの処理と言う感じです。
PCまたはタブレットから認証を始める場合
次はクロスデバイスなフローです。
- サービスからデジタル認証アプリを開く : 始めましょう
- 二次元コードの読み取り : 左上にデジタル認証アプリとあるので民間/行政サービスが出しているわけではなくここだけデジタル認証アプリと連動するWebアプリ？が出している感じかな
- 6桁の数字を入力 : デジタル認証アプリの方で6桁の数字を表示、元の画面に入力
- 認証手順の確認
- 利用者証明用電子証明書の暗証番号の入力
- 【一部サービスのみ】券面事項入力補助用の暗証番号の入力
- マイナンバーカードの読み取り
- サービスへの認証を許可
- 認証が完了
パスキーのhybrid transportのようにBLE接続による近接チェックなどはないので、2のQRコードは誰かに送られる可能性はありますが、秒数が30秒かつ3でアプリに表示された文字列をPC側に入力する必要があるのでその難易度を上げたい気持ちが伝わってきます。これで十分なのかは検証の必要があるかもしれません。
OIDC CIBAでは数字合わせみたいなのが行われたりしますが、PC画面に表示された値をデジタル認証アプリ側に入力よりも今回のような逆の入力の方が安全なのか、あたりも良い機会なので検証されてほしいですね。
4以降は一緒です。
デジタル認証アプリサービス(アプリ+バックエンド)はマイナンバーカードを用いた当人認証を実施
最初にこう書いた通り、民間/行政サービスはマイナンバーカードのあれこれに直接関与しません。デジタル認証アプリが毎回よしなにやってくれます。クロスデバイスの部分も同じです。なので、民間/行政サービスは自分たちのサービスからデジタル認証アプリサービスにユーザーを誘導するだけ、戻ってきたらその続きをするだけと言うことです。その行ったり来たりがいわゆるOIDC Danceというわけです。
ここまでを整理すると
- デジタル認証アプリサービスがユーザーをマイナンバーカード+暗証番号を用いて当人認証を行う
- 民間/行政サービスがOIDCのRP、そしてデジタル認証アプリサービスがIdPとなってID連携する
という感じです。OIDCの認証フローを覚えたらいいだけですね。覚えましょう。
採用されている標準化仕様
OIDCやOAuthには仕様がたくさんあるのですが、今回の案件に関わるものをピックアップしてみました。
-
OpenID Connect Core 1.0 : 基本
- RFC6749 - The OAuth 2.0 Authorization Framework : 認可コードフロー
- RFC6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage : APIアクセス部分の仕様
- RFC7515 - JSON Web Signature (JWS) : IDトークンの署名検証方法
- RFC7517 - JSON Web Key (JWK) : IDトークンの署名検証に使う公開鍵情報
- RFC7519 - JSON Web Token (JWT) : IDトークンのPayloadに関する情報
- RFC7636 - Proof Key for Code Exchange by OAuth Public Clients : 認可リクエスト、アクセストークンリクエストで利用するパラメータ
-
OpenID Connect Back-Channel Logout 1.0 : ログアウト、利用端末の解除、退会時にIdPからRPに送られるログアウトイベント
-
OpenID Connect Session Management 1.0
session_stateの定義
-
OpenID Connect Session Management 1.0
- OpenID Connect Discovery 1.0 : OpenID Configuration
- RFC7521 - Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants, RFC7523 - JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants クライアント認証
一見たくさんありそうですが、そんなでもないです。重複と言うかざっくり説明されてこの仕様を参照しろ、みたいになってるものも含んでいます。
勘所
SPAやネイティブアプリのClientTypeはPublicなのでは問題
今回の認証フローでは認可コードフローだったり、private_key_jwt 形式のクライアント認証が必要だったりするわけですが、まず出てくるのがSPAやネイティブアプリ単体のような "Public Client から使って良いのか問題" でしょう。無難なのはバックエンドとの組み合わせで ClientType を "Confidential" にしてしまうやり方です。
パスキーとの関係
パスキーで実現できることは当人認証であり、デジタル認証アプリとのID連携では身元確認にも利用可能です。なので、単純に並ぶ存在ではないですが、組み合わせをかんがえてみると良いでしょう。
まずはデジタル認証アプリの弱点をパスキーで補う使い方です。現状だと認証フローのたびにマイナンバーカードと暗証番号による当人認証が要求されるようなので利便性は高くありません。ログイン成功した環境でパスキー登録を促し、次回以降はパスキーでログインさせることで利便性を高めることができるでしょう。
クロスデバイスの認証フローを考えたときは、パスキーの弱点をデジタル認証アプリで補う使い方も考えられます。パスキーに非対応なOS/ブラウザ環境でも、デジタル認証アプリとのID連携では、QRコードを使った接続が可能です。認証フローのUXは手間がかかるかもしれませんが、当人認証の安全性を保ちつつ利用可能な範囲を少しでも広げられる効果はあるでしょう。
まとめ
概要と採用されている標準化仕様、そして勘所を紹介しました。
今回出されたAPIリファレンスを読んでみて、これは何の意味があるパラメータなんだろうとか、気になることが出てきたら仕様をあたってみましょう。
それでもわからなかったら私にでも質問してみてください。
ではまた！
Discussion