OAuth 2.0とは｜アプリが求めた権限のうち、90日で一度も使われなかったのは47.5%だった

解こうとしているのは「語を預ける形」

仕様は、外部のアプリが利用者の語を保管せざるを得なかった状況を問題として挙げています。

OAuth 2.0の出発点は、それ以前の形の問題です。仕様は次のように書いています。

外部のアプリは、資源の持ち主の資格情報を、以後の利用のために保管することを求められる。多くの場合、平文のパスワードとしてという記述です。

問題は保管そのものです。預けた先の数だけ、語の置き場所が増えます。

何が困るか

1. 語が複製される。預けた先の数だけ置き場所が増える
2. 範囲を区切れない。語を持てば何でもできる
3. 取り消せない。語を変えると他の連携も切れる
4. 期限がない。預けたままになる

2番目が、あとで測る部分につながります。語には範囲という考え方がありません。

使い回しがある場合、1番目はさらに効きます。1つのアプリから漏れると何個に波及するかはSSOの記事で数えていて、平均23.9個でした。

置き換えたもの

OAuth 2.0では、語の代わりに引換券を渡します。引換券には範囲と期限をつけられます。

この2つがつくことで、上の4つのうち3つが解けます。残る1つ、複製の問題は引換券についても起こります。

アプリが求めた権限のうち、90日で一度も使われなかったのは47.5%だった

求める側の見積もりは多めになります。渡す側で減らしてよいと仕様も定めています。

OAuth 2.0では、求められた範囲をそのまま渡す必要がありません。仕様の規定はこうです。

認可サーバーは、方針または資源の持ち主の指示に基づいて、依頼側が求めた範囲を全部または一部、無視してよいというものです。

では、どれだけ減らせるのか。求めた権限と実際に使った権限を分けて数えました。

90日ぶんの利用を見る

操作の種類を60個、アプリを40個としました。アプリごとに求める権限と使う権限を作ります。

操作の種類 60個・アプリ 40個。90日ぶんの利用を見る
1つのアプリが求める権限は平均 5.0個、そのうち実際に使うのは平均 2.6個

引換券に載せる範囲      漏れたとき行える操作  全体に対する割合  求めたのに使わない権限
全部載せる                                  60.0個            100.0%                    0.0個
求めた通りに載せる                               5.0個              8.4%                    2.4個
使った分だけに絞る                               2.6個              4.4%                    0.0個

全部載せると60個です。引換券が1つ漏れれば、何でもできます。

求めた通りに載せると5.0個、全体の8.4%になります。ここまでは範囲を区切るだけで効きます。

そこからさらに半分

右端の列を見てください。求めた5.0個のうち2.4個は90日間使われませんでした。

割合にして47.5%です。求める側は、将来使うかもしれない分まで含めて求めます。

使った分だけに絞れば2.6個・4.4%まで落ちます。求めた通りに渡す場合の半分です。

そのためには記録が要ります。実際に使われた操作を残しておかないと、どれを外せるか分かりません。

引換券そのものが資格情報なので、扱いは語と同じ

範囲と期限がついた分だけ被害は小さくなります。ただし持てば使えることは変わりません。

OAuth 2.0の引換券は、仕様の上でも資格情報として扱われます。アクセストークンとは、保護された資源へ到達するために使われる資格情報であるという定義です。

資格情報である以上、持っている側が使えます。誰が持っているかを確かめる仕組みは、既定では入っていません。

どこを通るか

引換券は、発行されてから使われるまでにいくつかの場所を通ります。通る場所の数だけ、漏れる機会があります。

だから範囲と期限が効きます。前の計測でいえば、漏れたときに行える操作が60個か2.6個かという違いです。

期限と作り直し

期限を短くすれば、漏れたときに使える時間が減ります。ただし作り直しの回数が増えます。

この釣り合いはパスキーの記事で数えていて、15分から60分にしても入力し直しは8%しか減りませんでした。

引換券の場合は、作り直しを自動でできる分だけ短くしやすいものです。利用者の手を止めずに期限を縮められます。