現状のCentral Account ChooserやGoogle Identity Toolkitは、筆者の目から見ても決して使いやすいものではありません。Account Chooserが本来の「セキュリティと使いやすさの両立」を実現するには、まだ少し時間がかかるでしょう。
そこでここからは、今後Account Chooserの発展に関わりそうな技術をいくつか紹介します。
OpenID Connectの仕様の中に、“self-issued IdP”というものが存在します。これはスマホアプリがIdPとなる場合など、中央の認証サーバなしにIdPを実装するための仕様です。
まだ実際のサービスとしてリリースされたものがないので説明しにくいのですが、iOS向けFacebook SDKのように、IdPとなるアプリ(公式FBアプリ)と、RPとなるアプリ(foursquareアプリなど)が連携し、パスワード入力なしに認証を可能にするといったことを、FacebookやLINEほどシェアが高くないアプリでも実現可能にするのが、“self-issued IdP”です。
このself-issued IdPですが、実現するには、デバイス上にIdPが利用できるセキュアストレージが存在することが絶対条件になります。残念ながら現状のWebブラウザにはセキュアストレージが存在しないため、ブラウザ上でself-issued IdPを実現することは不可能です。
しかし現在、W3CのWeb Cryptography WGで議論されているWeb Crypto APIがブラウザに実装されれば、self-issued IdPをブラウザ上のJSアプリとして実装することも可能になります。これはCentral Account Chooser自体がself-issued IdPになれるということを意味します。
Central Account Chooser自体がIdPとなれれば、OpenIDやOAuth経由でのログイン結果をCentral Account Chooserがキャッシュして、それをセキュアに使いまわすことも可能になり、UXもずいぶん改善できると期待しています。
Web IntentsやRegister Protocol Handlerなど、W3Cではブラウザ自体にDiscovery機能を埋め込む動きが見られます。これらはちょうど、AndroidのIntentやiOSのCustom Schemeと同様のものと思っていただければ分かりやすいかと思います。
現状のCentral Account Chooserが行っているのも、「そのユーザーが使っているIdPを探す」というDiscoveryですので、ブラウザ自体にDiscovery機能が埋め込まれれば、www.accountchooser.comにリダイレクトすることなくCentral Account Chooserと同様の機能が提供できます。
上記のWeb Crypto APIと並んで、このブラウザ組み込みDiscovery機能についても、より使いやすいAccount Chooserを実現する要素になると思います。
今回は、OpenID Foundationが進めるAccount Chooserというプロジェクトを紹介し、その実装例として、OpenID Foundationが提供しているCentral Account ChooserとGoogleが提供しているGoogle Identity Toolkitという2つのプロダクトを紹介しました。
まだAccount Chooserの実装として「本当に使いやすい!」といえるプロダクトは存在しません。しかし今後、ブラウザ自体の高機能化も相まって、本来の目的である「セキュリティと使いやすさの両立」を実現できると思われます。
一方で、ブラウザ以外のシチュエーション(スマホ、TV、自動車など)でのAccount Chooserの実装なども、ニーズとしては高まっていくものと思われます。そういった場面では特に、Account Chooserだけでなくself-issued IdPというコンセプトも有用になるでしょう。
現状ではあまり注目されているとは言い難いこれらのプロジェクトですが、この記事をきっかけに、興味を持ち、使ってみていただけると幸いです。
さて、この連載の私の担当記事は、これで終了です。次回は@ritouから、UMA(User Managed Access)というプロトコルについて紹介してもらいます。
Copyright © ITmedia, Inc. All Rights Reserved.