このビデオは、2020 年 4 月 22 日に開催した弊社勉強会のプレゼンテーション録画のパート 8 です。 識別子型アクセストークンと内包型アクセストークンの比較を、 Authlete の川崎貴彦がお話しします。
川崎: そろそろまとめに入ります。 識別子型と内包型を比較します。 表に書くとこんな感じです。
川崎: 長さですが、識別子型のアクセストークンは固定長になっています。 内包型の場合には、アクセストークンにひもづく情報の量によって可変です。
とくに、Rich Authorization Requests みたいな、 巨大な認可情報を埋め込む場合、 アクセストークンのサイズは、もう途端に大きくなります。
認可リクエストが大きくなることに対して、 Pushed Authorization Requests エンドポイントを定義したぐらいなのに、 そのサイズのアクセストークンができてしまったらどうなの、 という問題が起こります。
川崎: 情報の置き場所について、識別子型は認可サーバーのデータベース内、 内包型はアクセストークンの内部です。
アクセストークンの内部に置くんですが、 実質的には、クライアント側に置いているのと一緒です。
川崎: 情報の取得方法は、（識別子型は）イントロスペクション、 内包型はアクセストークンの中に入っています。
こんな感じで、いろいろ比較があります。 今まで述べていないことで言うと、 発行済みアクセストークンの一括削除・属性更新・一括取得があります。
こういう処理は、 アクセストークンがサーバー側にある、識別子型の場合にはできます。
一方内包型の場合は、サーバー側に無いので、 やろうと思っても実現不可能です。
情報漏えいに関しては、 識別子型の場合には、外部漏えいに関してはとくに心配する必要はありません。
内包型の場合には、 まず暗号化してなければ、すべての情報がそのまま漏えいしていきます。 暗号化すれば隠せますが、 情報が攻撃者の手元にある点は一緒です。
鍵が危殆化したときの対策が必要になります。 鍵が漏れた場合には暗号を解かれてしまうので、 情報漏えいになってしまいます。
アクセストークンの機能拡張で、 アクセストークンに秘密情報をひもづけておく機能を実装する場合があります。
たとえば Authlete はそういう機能を持っていますが、 識別子型の場合、認可サーバーのデータベースに、 そういう情報を保存しておくことで実現できます。
内包型で同じことをやろうとすると、 やはり暗号化して含めなくてはなりません。
このように pros/cons がいろいろあります。 これを見てどちらの実装を選ぶか、ですね。
ぼくが Authlete の実装を開始したときには非常に悩みました。 どちらにしようか、ずっと長い時間悩んで、けっきょく識別子型を選びました。
決定的に重要だったのは、 アクセストークンを即座に削除できるかどうかです。 セキュリティ上、ぼくは重要だと思ったので、けっきょく識別子型を選びました。
