このビデオについて

このビデオは、2020 年 4 月 22 日に開催した弊社勉強会のプレゼンテーション録画のパート 8 です。識別子型アクセストークンと内包型アクセストークンの比較を、 Authlete の川崎貴彦がお話しします。

文字起こし（ログを元に再構成）

川崎: そろそろまとめに入ります。識別子型と内包型を比較します。表に書くとこんな感じです。

川崎: 長さですが、識別子型のアクセストークンは固定長になっています。内包型の場合には、アクセストークンにひもづく情報の量によって可変です。

とくに、Rich Authorization Requests みたいな、巨大な認可情報を埋め込む場合、アクセストークンのサイズは、もう途端に大きくなります。

認可リクエストが大きくなることに対して、 Pushed Authorization Requests エンドポイントを定義したぐらいなのに、そのサイズのアクセストークンができてしまったらどうなの、という問題が起こります。

川崎: 情報の置き場所について、識別子型は認可サーバーのデータベース内、内包型はアクセストークンの内部です。

アクセストークンの内部に置くんですが、実質的には、クライアント側に置いているのと一緒です。

川崎: 情報の取得方法は、（識別子型は）イントロスペクション、内包型はアクセストークンの中に入っています。

こんな感じで、いろいろ比較があります。今まで述べていないことで言うと、発行済みアクセストークンの一括削除・属性更新・一括取得があります。

こういう処理は、アクセストークンがサーバー側にある、識別子型の場合にはできます。

一方内包型の場合は、サーバー側に無いので、やろうと思っても実現不可能です。

情報漏えいに関しては、識別子型の場合には、外部漏えいに関してはとくに心配する必要はありません。

内包型の場合には、まず暗号化してなければ、すべての情報がそのまま漏えいしていきます。暗号化すれば隠せますが、情報が攻撃者の手元にある点は一緒です。

鍵が危殆化したときの対策が必要になります。鍵が漏れた場合には暗号を解かれてしまうので、情報漏えいになってしまいます。

アクセストークンの機能拡張で、アクセストークンに秘密情報をひもづけておく機能を実装する場合があります。

たとえば Authlete はそういう機能を持っていますが、識別子型の場合、認可サーバーのデータベースに、そういう情報を保存しておくことで実現できます。

内包型で同じことをやろうとすると、やはり暗号化して含めなくてはなりません。

このように pros/cons がいろいろあります。これを見てどちらの実装を選ぶか、ですね。

ぼくが Authlete の実装を開始したときには非常に悩みました。どちらにしようか、ずっと長い時間悩んで、けっきょく識別子型を選びました。

決定的に重要だったのは、アクセストークンを即座に削除できるかどうかです。セキュリティ上、ぼくは重要だと思ったので、けっきょく識別子型を選びました。

個人情報の取扱いに同意する