券を5000枚作り、そのうち1983枚に細工をしました。署名を確かめると42.6%が止まります。
残りは署名が正しい券です。発行元・宛先・期限・合言葉まで見て、ようやく99.9%になりました。
身元を伝える形が決まっているので、提供する側を替えても受け取る側の作りが変わりません。
OpenID Connectが与えるのは、共通の確かめ方です。仕様はこう述べています。
これにより依頼側は、認可サーバーが行った認証にもとづいて利用者の身元を確かめられるようになり、あわせて利用者の基本的な属性を、相互に運用できる形で得られるようになるという記述です。
「相互に運用できる形」が効きます。提供する側を替えても、受け取る側の確認手順は変わりません。
3番目が実務で効きます。確認の実装を1つ書けば、提供元が増えても使い回せます。
逆に言えば、その1つの実装に抜けがあれば、すべての提供元に対して抜けます。次の節で、どこが抜けやすいかを数えます。
業務のアプリをまとめる場合、この取り決めが使われます。アプリ側が語を持たなくなるのはこの形だからです。
まとめたときの波及の広さはSSOの記事で数えていて、アプリ1個の漏えいが平均23.9個から0個になりました。
It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.原文OpenID Foundation「OpenID Connect Core 1.0」 この内容の有効期限2027-02-18
残りは署名が正しい券です。誰に向けた券か、いつまで有効かを見なければ通ります。
OpenID Connectが足す中心は、身元を伝える券です。仕様はOpenID ConnectがOAuth 2.0に加える主たる拡張は、利用者を認証できるようにするためのIDトークンという構造であると述べています。
この券をどこまで確かめるかで、通るものが変わります。券を作って壊して数えました。
5000枚の券のうち1983枚に細工をしました。署名の書き換え、鍵の取り替え、宛先や期限の細工などです。
券 5000枚。うち細工したもの 1983枚（39.7%） 確認を1つずつ足していったときに、何枚を止められるか 足した確認 止めた枚数 正しく止めた 誤って止めた 検出率 形として読めるか 0枚 0枚 0枚 0.0% 署名の方式が想定通りか 287枚 287枚 0枚 14.5% 署名が合っているか 844枚 844枚 0枚 42.6% 発行元が合っているか 1119枚 1119枚 0枚 56.4% 宛先が自分か 1397枚 1397枚 0枚 70.4% 期限が切れていないか 1668枚 1668枚 0枚 84.1% 合言葉が使い回しでないか 1982枚 1982枚 0枚 99.9%
署名まで確かめた時点で42.6%です。半分以上が残ります。
残った券は署名が正しいものです。正規の発行元が正しく署名した券が、別の用途で使われています。
どの確認がどれを止めているかも数えました。1対1で対応します。
券 5000枚。細工の種類ごとに、どの確認で止まるかを見る 細工の種類 枚数 止めた確認 止まらなかった枚数 正しい券 3017枚 （止まらない） 3017枚 署名を書き換えた 268枚 署名が合っているか 0枚 署名の鍵が違う 289枚 署名が合っているか 0枚 署名なしと言い張る 287枚 署名の方式が想定通りか 0枚 発行元が違う 275枚 発行元が合っているか 0枚 宛先が違う 278枚 宛先が自分か 0枚 期限が切れている 271枚 期限が切れていないか 0枚 使い回しの合言葉 315枚 合言葉が使い回しでないか 1枚
1つの確認を落とすと、対応する細工がそのまま通ります。代わりに止めてくれる確認はありません。
3行目に注目してください。署名なしと言い張る券は、署名の確認では止まりません。方式を先に確かめる必要があります。
確認を足すごとに検出率が段で上がる。抜けた分はそのまま通る。
The primary extension that OpenID Connect makes to OAuth 2.0 to enable End-Users to be Authenticated is the ID Token data structure.原文OpenID Foundation「OpenID Connect Core 1.0」 この内容の有効期限2027-02-18
許す幅は、そのまま期限を延ばしたのと同じです。運用の都合が、確認の厳しさを削ります。
OpenID Connectは、別の取り決めの上に乗っています。仕様はOpenID Connect 1.0は、OAuth 2.0という取り決めの上に乗る、単純な身元の層であると定めています。
下の層は何ができるかを扱い、この層は誰かを扱います。取り違えると、権限の券を身元の証明として使ってしまいます。
権限の券には、誰に向けて出されたかを示す項目がありません。別のアプリ向けに出た券でも、そのまま通ってしまいます。
身元の券には宛先が載ります。前の節の表でいえば、宛先の確認が278枚を止めていました。
下の層の権限の絞り方はOAuth 2.0の記事で数えていて、求めた権限の47.5%が使われませんでした。
期限の確認には、実務上の問題があります。端末とサーバーの時計がずれるためです。
そこで多少の幅を許すのが普通です。その幅が何を通すかを数えました。
期限が切れた券 20000枚。切れてからの経過は 0〜3600秒（短いほうに偏る） 時計のずれを許す幅を広げると、そのぶん通ってしまう 許す幅 通ってしまう枚数 割合 切れてから通る最大 0秒 0枚 0.00% 0秒 30秒 1874枚 9.37% 30秒 60秒 2667枚 13.33% 60秒 300秒 5901枚 29.50% 300秒 600秒 8237枚 41.19% 600秒
60秒許すと13.33%が通ります。600秒なら41.19%です。
右端の列が要点です。許した幅がそのまま、期限を延ばした時間になります。
だから幅は券の有効期限と比べて決めます。期限が15分の券に600秒の幅を許せば、実質は25分です。
許す幅は、そのまま期限の延長になる。
細工の種類とその割合はこちらで作ったもので、実際の攻撃の分布ではありません。期限切れの券が切れてからどれだけ経っているかも式で置きました。この分布が変われば、許す幅ごとの割合も変わります。一方、確認と細工が1対1で対応し、落とした確認の分がそのまま通るという関係は、分布によりません。署名の検証そのものはNode同梱の仕組みで実際に行っています。
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol.原文OpenID Foundation「OpenID Connect Core 1.0」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る