初めに

こんにちは、グローバル開発グループでID Platformを開発しているリョウです。KINTOサービスは既に複数の国で展開しており、今後もさらに多くの国へ展開される予定です。その中で、ID Platform開発チームのミッションは「世界中のお客さまが国を跨いで一つのIDで、全てのKINTOサービスをスムーズに利用出来るIDシステムを構築する」ことです。その中で、現在FIDO Proof of Concept (PoC)の内容を皆さまにご紹介したいと思います。

アイデンティティ・プロバイダ、IDプロバイダ　IDP

アイデンティティ・プロバイダ、IDプロバイダ（英: Identity provider、略してIdPまたはIDP ）は、プリンシパルのID情報を作成、維持、および管理し、フェデレーションまたは分散ネットワーク内の依存アプリケーションに認証サービスを提供するシステムエンティティである。
上記の「アイデンティティ・プロバイダ、IDプロバイダ（以下、IDP）」の説明は、IDPを聞いたことのない方は分かりにくいかと思いますが、簡単に言うと、IDPはユーザの管理、認証、認可を一連担当するシステムです。

---

FIDOの概念

既にFIDOの概念をご存知の方はいらっしゃると思いますが、FIDO(Fast IDentity Online)とは、一般的なID・パスワードでの認証方法と違い、パスワードレスでオンラインサービスのID認証を実行する新たな認証規格です。FIDOは「秘密鍵」と「公開鍵」の鍵ペアを利用しており、一般的な共通鍵手段より安全性が高い方法です。

---

FIDO認証の流れ

新規登録の流れは以下になります

登録済みユーザのログインの流れ

---

一般的な形との比較

一般的な形は：

1. ユーザがアカウント作成する時点でIDとパスワードのペアを設定
2. サーバーにてIDと暗号化パスワードをデータベースに記入
3. IDとパスワードをサーバーへ送って判断させる

FIDO認証メリット

FIDO認証は、パスワードレスで安全的に認証ができる新しい認証方法であり、FIDOを活用する事によって、パスワードを利用せずに公開鍵暗号で認証できます。ユーザにとって以下のメリットがあります。

1. サーバーが公開鍵を保存するので、ユーザの秘密情報を保存しない
2. 公開鍵暗号化採用してるので、共通鍵より安全性が高い
3. ユーザはパスワードを覚えなくてもログイン出来る
4. 指紋認証、顔認認証はパスワードを手入力するより操作利便性がある

---

実現したこと

FIDO PoCの目的としては、大きくわけると以下の２つとなります:

1. 現行IDシステムとにおける必要な調整、対応を実現すること
2. 社内、社外のIDシステムをFIDO利用する場合、両方とも簡単に導入出来る案を実現すること

上記の目的を合わせて、以下の４点を実現できました：

1. ECCやRSAの公開鍵を解析すること（目的１）
2. 生体認証によって作られた公開鍵をRDSに保存すること（目的１）
3. 認証が発生時点、正しく認証出来ること（目的１）
4. WebとAPI形両方対応出来ること（目的２）

---

工夫したこと

1. 基本設計階段でWebとAPI形式兼用

我々は、単にIDPを作る訳ではなく、KINTOのIDPとして世界中に展開しつつ、他のサービスにも導入してもらいたいと考えています。
KINTOの各サービスはAPI式で、簡単にFIDO機能を導入できるようにしており、また、他社の場合でもWeb形式でワンクリックで導入出来るように想定しております。
両方とも対応できる形を工夫してサービスを展開すると、さらに利便性が向上します。

2. プログラミング言語の変更

公式サイトで手に入れたサンプルコードは、フロントエンド・バックエンド両方ともJavaScriptで書かれています。Spring Bootを利用してサービスを展開中なので、新たな機能としてIDPに追加するとJavaScriptからJava上の変更が必要となります。
JavaScriptで利用されている外部ライブラリと同じ機能のJavaライブラリがない場合には、それを実現するためのコーディングが発生します。

PoC中に遭った問題

ユーザの認証を行う際に、時々RDSに保存された公開鍵に当たらないBugが発生しました。
Debugしてみたところ、RDSに保存されている公開鍵のIDはbase64エンコード済みの文字列は、JavaとJavaScriptのbase64エンコードする関数のエンコード結果が違いました。
JavaScript上では自動補足オフで実行しましたが、バックエンドのロジックをJavaへ移動する際、自動補足の設定に気付かず、Java自動補足を使用してしまいました。
自動補足をオフの状態に切替えることで、無事にBugを解決できました。

• Base64.getUrlEncoder().encodeToString(ID文字列)
  • 自動補足を使用したパターンでは、エンコーディング結果が４の倍数に足り無い部分は「＝」イコールマークで補足する
• Base64.getUrlEncoder().withoutPadding().encodeToString(ID文字列)
  • 自動補足オフモードの場合、エンコーディング結果はそのまま。

---

課題

FIDOによって、ユーザーは以前より便利で安全な方法でオンラインサービスを利用できるようになりましたが、その他にもまた幾つかの対応すべきことが残っています。

公開鍵管理に関する問題点：

• 同じデバイスで複数の公開鍵を追加できる

サーバーからは同じデバイスであることを認識できないので、同デバイス内で公開鍵の登録が何回でもできてしまいます。それによってゴミデータがRDSに保存されてしまいます。

• デバイスの切り替えなどによる公開鍵の再登録

デバイスの紛失や機種変更などによって、FIDOの再登録が必要です。再登録の際はその人であることを別の手段で確認する必要があるため、ID＆パスワード式より不便だと感じられます。

• 不要な公開鍵の管理

上記により、不要な公開鍵が生じます。ユーザーが公開鍵のID管理をできないので、公開鍵が無用になると、バックエンド上では公開鍵の有効性がわかりません。公開鍵が無効になっても、長い時間でRDS上に保存しないといけません。

---

まとめ

パスワードレスの形でより良い認証認可の体験をユーザに届きたいので、FIDOのPoCを実施しました。
PoCを実施した結果、有力なソリューションであると感じていると同時に、まだ公開鍵管理などの課題があると感じていますので、これからもしっかり検証をした上で開発を進めていきたいと考えています。

レファレンス

FIDO認証とは？
OpenID Connectとは？