0. はじめに、この記事について
ども！
毎年、年末が近づくにつれ、何か新しいことがしたいと思うものの、年々できなくなっていることに危機感を持ってるみやともです。
なんなら昔やっていたこともだんだん億劫になってくる昨今です。
さて、この記事は NEM Advent Calendar 2020 の13日目の記事です。
今回、ツイベガ君が最も得意なIdPの分野で勝負しようとのことで、また巻き込まれてしまいました。
というわけで、共同執筆でNEMを使ってブロックチェーン上にIdPを割と新しい感じで構築してみましたので、そのコンセプトを書きたいと思います。
ちなみに、僕がIdP & SPを、ツイベガがコンセプト発案 & 記事を実装していて、ツイベガは途中でSPの実装を諦めました。
1. NEM Authnの概要
どもども、ツイベガ君@痩せたろうです！
皆さん今日も認証してますか？
昔はシステムそれぞれにIDとパスワードが管理されていて、ユーザ側としては覚えるのが大変でしたね。
でも最近はひとつのシステムでログインしたら他のシステムでも使えるようになっていたり(シングルサインオン、SAML、OpenIDConnectなど)、指紋や顔を識別してセキュアに認証出来たり(FIDO2,WebAuthnなど)しています。
今回作ったNEM Authn は、NEMのトランザクションを使ってログインが出来るIdP(Identify Provide：認証情報提供者)です。
SP(Service Provider：IdPの認証情報を信頼してサービスを提供する)サイト側で少し対応頂くだけでNEMアカウントを使用したSSOが可能になります。
IdPは、ざっくりパスポートを発行する組織だと思ってください。
SPはパスポートを見せて航行する目的地だと思ってください。
事前に日本(IdP)でパスポートを発行しておくことで、外国(SPサイト)に行ったときにはパスポートを見せることで、どこの国の誰であるかを証明することが出来ます。
事前に日本と信頼関係を結んでいる国であればどこでも有効になるプロトコルです。
百聞は一見にしかずということで、まずはサンプルのSPサイトにログインして見ましょう。
① このサイトに飛びましょう
② サイト右上のLog inボタンを押します
③ 表示されたQRコードからNEMウォレットで0xemを送金するとログインできます
※1 2020/12/13現在 SignUP機能は未実装です。。
お手数ですが、別途NEMアドレスをツイベガもしくはみやともまでご連絡下さい
※2 また、IdP側のログを見て適宜手動で追加していくつもりです。やる気はあります。
今はまだプロトタイプですが、ログインができたらアカウントのNEMモザイクのギャラリーが表示されるはずです。
今後NEMアカウントを使うシステムにプラグインっぽく組み込めるようにするつもりです。
2. NEM Authnの概要
2–1 認証
ここでいう認証とは、システムが実施する本人確認のことを指します。
ユーザーごとに権限が存在したり、ユーザーごとに開示する情報を制御する場合、本人確認のために認証が必ず必要です。
で、おおよそ認証を行う手段には、だいたい３つくらいがあります。
- パスワードなどの本人の知識による認証
- セキュリティトークンなどの本人の所有権による認証
- 身体の固有パターンによる生体認証
今回、NEM Authnでは、認証手段の 2. 本人の所有権による認証で、NEMアカウントの秘密鍵の所有権を元に本人確認を行っています。
2–2 認可
認可とは、システムの権限確認のことです。
通常、認可を含むシステムでは、ユーザが認証(本人確認)された後に、そのユーザの権限（一般ユーザなのか、管理者なのか）に合わせた処理を実施します。
NEM Authnでは認可の判断にモザイク(NEMトークン)を利用します
そしてこれがNEM Authnの特筆すべきポイントにもなっています。
これを利用することで「NEMAuthn会員モザイク」を1枚以上持っていないとログイン出来ないシステムなどを容易に作ることが出来ます。
2–3 NEM AuthnにおけるIdPとSP
前述のパスポートの例でいえば、NEM Authn ではNEMアカウントを元にデジタルなパスポートを発行しています。
この仕組みによって、事前に信頼関係を結んだサイトにログインが出来ます。
(今はhttps://tomohidemiya.github.io/nem-authn-sp/のみ)
3. NEM Authnの優位性
NEM Authnが他の認証基盤に対して優位性があることはこんな感じだと思っています。異論は認めます。
3–1 NEMアカウントの保有者を特定できる
NEM AuthnではユーザIDに当たる部分がNEMアドレスになります。
そのため、NEMアドレスが必要なサイトを作るには持ってこいです。
3–2 NEMモザイクを権限管理に利用できる
認証したユーザーが所持しているNEMモザイクを権限管理に利用することが出来ます。
例えば何かの会員モザイクを販売して、その会員のみが閲覧可能なサイトや、割引モザイク、優待モザイクなどSPサイトで独自の意味をもつモザイクに対して、特定の処理を行う仕組みを作成することもできるでしょう。
他にも、別の用途で使用されていたモザイクを流用してシステムの権限管理をする事も出来るでしょう。
この辺はかなり応用が利くと思っています。
3–3 捨てアカウントの防止やアカウント流用を防止できる
SNSのようなサイトでは捨てアカウントによる誹謗中傷リスクがあります。
また、電子書籍のような有料コンテンツを購入するタイプのサイトの場合はアカウント情報を友人に貸すなどの流用されるリスクがあります。
NEM Authnを使って、例えば10000XEM の保持をしていないとサービスを利用出来ないように設定しておくことで、捨てアカやアカウント流用が困難になります。
NEM Authnのアカウント情報を渡すことはすなわちNEMの秘密鍵を渡すことになり、保持しているXEMを奪われる危険性があるからです。
4. NEM Authnの設計とプロトタイプ
4–1 設計
NEM Authn では、IDaaSであるAuth0を使用しています。
Auth0側にユーザーストアやSPサイトを管理する機能を簡単に、便宜的にそれを使っています。
（ただ認証画面はゴリゴリに書き換えていてあまり原型は留めていません）
ログイン画面ではNEMウォレットの仕様に則ったQRの請求書を発行しています。
各画面で必ず異なる識別子をメッセージに指定しており、これを使ってトランザクションを識別して認証しています。
この辺は少しダサいので、もうちょっとスマートにトランザクションを特定できないか検討を進めています。
3–2 プロトタイプ
Nem AuthnのプロトタイプサイトはGithubに公開しています。
なお、実装はVueですが、認証に関わるモジュールは `src/auth/index.js` のみで完結しています。
おそらくSignUpやSPの登録などいくつか必要な機能がありますが、順次作成していこうと思っています。
3–3 リスクとか課題とか
今見えてるのはこんな感じです。
順次解消していくつもりなので、やる気は多分あるんだと思います。
- QR読んだ端末で決済したのかわからない
メッセージ解読されてウニャウニャされるのやばい - モザイクでAuthorizationできる気がする。そこまで提供できそう
- そもそもAuth0とかいらん
- NEM2(symbol)ではメタデータとかを使えばよりスマートに出来そう
- パブリックチェーンのアカウント情報で認可するとか正気か？
4. 今後の展望
どなたかIdPとして採用してみる猛者はいないでしょうか？
プロトタイプの域を全く出ていないので、急に採用してくれ、とは全然思っていないのですが、コンセプトは結構自信があるので、興味ある方は連絡いただけると嬉しみです。
ちなみにプロトタイプのサイトはもう少しアップデートしていこうと思っていて、こんな感じのロードマップを考えています。
5. 最後に
NEM Authnを思いついたきっかけは2つあります。
ひとつめは、「NEM Login/とーくんぺーじ」という素晴らしいサービスの影響です。
※サービス自体は2019年9月末に終了されております
このサービスは、自身のNEMアカウントを使って登録することで、各ユーザがNEMやモザイクの所持量に合わせて閲覧できるサイトをいとも簡単に作れるというものでした。
当時、認証基盤に関わる仕事をしていた自分にとって、モザイク保持量をそのまま認可に使えるという発想はとても衝撃的なものでした。
今までの当たり前であった「管理者⇒ユーザの権限管理」というものから「ユーザ⇔ユーザの権限管理」という全く新しいモノの一端を垣間見た気がしました。
ふたつめは、システム側で発生する情報漏洩に対してユーザ側で出来ることがないという歯痒さです。
システム側にIDを管理されているということは、生殺与奪の権利を他人に委ねている状態ではないでしょうか。
NEM Authnで扱うIDのクレデンシャル情報は秘密鍵になりますが、これは一度たりともシステム側に秘密鍵を渡すことはありません。
そのため、生殺与奪の権利は常に自分にあるといえるかと思います。
ただ、その分情報漏洩したら全部自分のせいになるので、無限のリテラシーが必要になります。
DID/SSIのような自己主権型や分散型IDが提唱されているなか、それに近い形で既存の認証プロトコル(OpenIDConnect)にNEMブロックチェーンが適用出来ないか、という提案でした。
※DID/SSIはXembookさんの記事をご覧ください。
ん？！パブリックチェーンでやるな？！いいんだよ細かいことは気にしなくて。
