Symbolブロックチェーンでクラウドサービス不要のログインを概念検証する

今回はSymbolブロックチェーンを活用した認証基盤の構築について概念検証してみたいと思います。

:::note
Symbolはブロックチェーンに詳しくない他分野のスペシャリストでもローコード/ノーコードでセキュアかつデプロイレスなスマートコントラクトを記述できるブロックチェーンとして日本のエンジニアや研究者を中心に注目されていて、いまでは元ビットコインのPoWやイーサリアムのプロトコルの改善提案者がコアチームに参入するなど新しい経済圏を実現するプラットフォームとしてその可能性が期待されています。
:::


# ログイン

KYCなどが済んだユーザに対して、譲渡不可・リボーク(収受)可能なトークンをログインチケットとして付与します。（ユーザが秘密鍵を所有しない場合は新規にアカウントを生成してそこに付与します。）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/29187/dacfeffb-64d6-087e-8c64-3b286096e636.png)



以後、ログインを希望するユーザに対してログインチケットをリボーク可能かどうかでログイン可能かどうかを判断します。2重ログインを禁止したい場合は、ユーザのログアウト・タイムアウトを判断した後、ログインチケットを返却します。2重ログインも許容できる場合はリボークトランザクションと付与トランザクションのアグリゲートトランザクションで早々に再交付しておきましょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/29187/bd55af7c-5e0b-108b-f2ca-9f9919b9fd3b.png)


# セッション管理

今回はセッションハイジャックが困難な、1度しか使えない有効期限つき(30分)ワンタイムセッションを実現します。

##### セッションキー発行

ログイン可能と判断できたユーザに対して、セッションキーを付与します。
最初のセッションキーはユーザからログインチケットを収受したリボーカブルトランザクションのHash値です。


同時にそのHash値をバリューとしたメタデータを、ユーザの公開鍵をキー値としてサービスプロバイダ自身に登録しておきます。これが未使用Hashの証明になります。（１アカウントに登録できるメタデータの最大数にご注意ください。ユーザのアカウントにメタデータとして登録する方法もありますが、その場合はユーザ側の秘密鍵が必要になります）

サービスプロバイダ.metadata{Key:Value} = {ユーザーの公開鍵:セッションキー(リボーカブルTX.hash or セッション更新TX.hash)}

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/29187/7740a02b-55d7-7d5b-1717-9be3d873857e.png)


##### セッションキー更新

ユーザはページ遷移ごとに、セッションキーを秘密鍵で署名した値をサービスプロバイダへ提出します。この作業にブロックチェーンは必要ありません。
サービスプロバイダはセッションキーからブロックチェーンへ照会し、そのTXのタイムスタンプと提出者のアカウントを確認します。（ユーザが署名できない場合はサービスプロバイダ自身が発行したトランザクションの情報を信用してユーザを特定します）

タイムスタンプが現在時刻から30分以上経過している場合は、後述のタイムアウト処理を実行します。また、受け取ったセッションキーがメタデータに登録されていない場合も無効なワンタイムセッションとしてタイムアウト処理を実行します。

セッションキーの更新はユーザのパブリックキーをメッセージに含めてサービスプロバイダ自身にTX送信し、その時のトランザクションハッシュ値をユーザに伝えます。同時にハッシュ値を未使用のセッションキーとしてメタデータに更新しておきます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/29187/a4376818-3ce7-931d-c15f-7ed3c2142c1d.png)




##### タイムアウト

セッションキーに紐づけられたトランザクションが古い場合、ユーザにログインチケットを返却しタイムアウト処理を行います。ユーザは再び秘密鍵を使用してログイン申請に署名する必要があります。ユーザがセッションキーを紛失した場合は、別途KYC手段によりログインチケットを再発行します。

##### 情報提供

セッションの検証により所有者が特定できたら、紐づくデータをユーザに開示します。
今回はユーザによるセッションキーへの署名で所有者を特定しましたが、ユーザによる署名が困難な場合は、サービスプロバイダ側のDBでセッションと対応するアカウントリストを保有しておいてもいいかもしれません。もちろんセッションキーはHTTPSなど別のセキュリティで保護する必要が出てきます。


# まとめ

今回はKYCがあるシーンでの有効期限つきワンタイムセッションという認証基盤について考えました。少しセキュリティを厳密に定義しましたのでブロックチェーンに依存する部分が多いですが、タイムアウトやセッションの再利用など要件に応じてブロックチェーンへの依存度を低めることも可能です。要点はトランザクションハッシュがそのままセッションキーとして利用できるという点で、ログインや画面遷移するたびにトークンが貯まるといった仕組みへ展開していくことが簡単なことを感じていただければと思います。逆にページ遷移するたびにトークンを消耗していくようなサイト構築も可能でしょう。

また、クラウドサービスなどに依存しない認証基盤の構築は非常に興味深いテーマだと思います。
今回は単純なテーマで検討しましたが、今後ブロックチェーンが普及するとサービスプロバイダが複数にわたるといったユースケースが増えてきます。そういったときに認証基盤を切り離すことが出来れば、よりフラットな経済圏を構築することが出来るかもしれません。


# 追記
現在この記事が注目されているようですので、お勧めの記事を紹介しておきます（順次追加しております）。

##### Symbolブロックチェーンの可能性を感じてみたい方

https://qiita.com/monakaJP/items/d819e8d0b01902689071

https://qiita.com/ry0-cha-ng/items/d3cbe46f10d7b632bce4

https://qiita.com/nabe387690473/items/c2cd75dc01f19a32aaad

https://nemlog.nem.social/blog/67337

https://www.nft-drive.com/service/index.html


##### 他の技術とSymbolを組み合わせてみたい方

https://medium.com/opening-line/unity%E3%81%A7%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B6%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E5%AE%9F%E8%A1%8C%E3%81%97%E3%81%9F%E3%81%84%E3%82%93%E3%81%98%E3%82%83-338dedca1f49

https://medium.com/opening-line/unreal-engine4%E3%81%A7%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B6%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E5%AE%9F%E8%A1%8C%E3%81%97%E3%81%9F%E3%81%84-a65f366cd756

https://qiita.com/tuibegakun/items/55e41dad12df712c4b7c

https://nemlog.nem.social/blog/69241

##### とりあえず送金を試してみたい方

https://qiita.com/nem_takanobu/items/e2b1f0aafe7a2df0fe1b

https://qiita.com/nem_takanobu/items/f3c02caa17ad385b6155

https://qiita.com/nem_takanobu/items/545a1b7fa98683a4c0da