あなたの荷物は、預かり所にある
写真も、連絡先も、書きかけの文章も、あなたのものは預かり所にしまってあります。
そこへ別のお店がやってきて、「あなたの荷物をちょっと使わせてほしい」と言う。写真を印刷したい、連絡先に招待を送りたい。
だから、合鍵を渡す
あなたのパスワードをお店に教えるのは、家の鍵をまるごと渡すようなものです。そうはしません。
代わりに預かり所が合鍵を作ります。開けられる棚は限られていて、期限もある。これが OAuth のやっていることです。
合鍵には、誰の鍵か書いていない
合鍵が言っているのは 「この棚を開けてよい」 だけです。誰の棚なのかは、どこにも書いてありません。
ところがお店がやりたいのは、たいていログインでした。「鍵を持っている＝本人だろう」で済ませたくなる。
でも鍵は落ちていることもあれば、人から借りたものかもしれない。持っていることは、本人であることの証明になりません。
だからみんな、中を覗いて推測した
誰の鍵か知りたいお店は、もらった鍵で棚を開けて、中の書類から名前を読むことにしました。
ところが預かり所ごとに、名前の置き場所も書き方も違う。預かり所の数だけ、読み方を書く羽目になりました。
鍵に、名札を添えて渡す
OIDC がしたのは、預かり所の仕組みを作り直すことではありません。合鍵はそのまま、名札を一枚添えただけです。
名札には「この人を確かに確認しました」と書いてある。仕様の言葉では ID トークン。
これで「開けてよい」と「これは誰々です」が、別々の紙に分かれました。
名札には、必ず 5 つ書いてある
推測が要らなくなったのは、名札の書式が決まっているからです。どの預かり所の名札でも、この 5 つは必ずあります。
| 名札に書いてあること | 仕様の名前 |
|---|---|
| どこの預かり所が出したか | iss |
| 誰のことか | sub |
| どのお店宛か | aud |
| いつまで有効か | exp |
| いつ出したか | iat |
名札には、封がしてある
名札はただの紙ではなく、預かり所の封がしてあります。仕様の言葉では署名です。
だからお店は、名札を受け取った時点で確かめられます。棚を開けに行く必要がありません。
途中で誰かが名前を書き換えれば、封が合わなくなって分かります。
名札が欲しいときは、そう言う
合鍵だけが欲しい日もあります。だから名札は頼んだときだけ出ます。
頼み方は決まっていて、お願いの中に openid という一語を入れる。これが入っていなければ、預かり所は今まで通り合鍵だけを渡します。同じ窓口が、言い方ひとつで両方に使えます。
- 言わなかった
- 合鍵だけ棚を開ける許可。誰かは分からない
- openid と言った
- 合鍵 + 名札許可に加えて、確かめられる身元
ほんとうは、こういう話でした
| たとえ | ほんとう |
|---|---|
| 預かり所 | 認可サーバ / リソースサーバ |
| お店 | クライアント（アプリ） |
| 合鍵 | アクセストークン |
| 開けてよい棚 | スコープ |
| 名札 | ID トークン |
| 名札の封 | JWS による署名 |
| 宛名 | aud クレーム |
| 合鍵の仕組み | OAuth 2.0 |
| 名札を足した約束 | OpenID Connect |