Decentralized SSO
Decentralized SSOは、SSOを分権化することで、セキュリティを向上させる仕組み・ブラウザ拡張のソフトウェアです。 この作品は私が普通科の高校生だった頃（2020の春頃）に制作し、U-22プロコンBest40の評価を頂いた処女作（Best40程度では処女作に入らないかもしれませんが）です。 U-22には、Aoiという作品名で提出しています。
背景
皆さまご存じの通り、SSO(Single Sign On)はその利便性から、広く普及しています。 しかし広い意味でのセキュリティ的な懸念があります。 つまり、SSOを提供する主体（Trusted Party）が絶対的な権威となり、利用者の正当性を保障するということです。 SSOを利用する主体（Relying Party）は利用者の正当性を根拠なく信じます。 この正当性というのは、利用者がBotでないこと、利用者が本人であること、利用者が正当な目的で利用していることなどです。
一つ例を挙げましょう。 TwitterはSSOを提供しています。 もしElonMuskが狂ってしまい、TwitterのSSOでなんらかの不正な認証が行われるとしたら？ 世の中のサービスは大混乱です。
TrustedPartyが保障する利用者の正当性についての情報がより信頼できればRelying Party側はハッピーです。 では、どうすれば情報の信頼性が向上するのでしょうか？
解決策
複数のTrusted Partyから利用者の正当性に関する情報を得ることが出来れば、情報の信頼性を高めることができます。 これが大きな方針です。
Decentralized SSOでは、利用者のアカウントを公開鍵として表現します。 Decentralized SSOの利用プロセスはシンプルで、次のようなものです。
- 利用者は、Decentralized SSOを利用するTrusted Partyにアクセスし、会員登録を行う。
- 利用者は、Trusted Partyの内部アカウントと拡張機能のアカウントを紐づけます。
- 利用者は、この1~2を他のTrusted Partyでも同様に行います。ただし、拡張機能側のアカウントは１つです。
- そして、とあるRelying Partyを利用し始めるとき、その公開鍵利用してログインできます。
- Relying Partyは自分が比較的信頼する複数のTrustedPartyから、利用者の公開鍵のハッシュ値をもとにして利用者の正当性を確認します。
これだけです。 これだけで、SSOの信頼性が向上します。 公開鍵を利用するということがポイントですね。
この方法の問題点
ただしこれにはいくつかの問題点があります。
- 公開鍵とサービス内部のアカウントを紐づけることで、より多くのサービスに渡って利用者がプロファイリングされる。
- 統一された規格を利用する必要があるが、標準化のID（ Internet Draft ）提出などを行っていない。
ただし、Metamaskなどのブラウザウォレットの普及によって、2020年ほど普及のハードルは高くないと思います。 これらの問題点が解決されることを願いつつ、私は今日も自分の興味に従い他の領域に足を踏み入れます。 いつかこの作品にひょっこり戻ってくるかもしれません。