昔から、﹁OpenIDは認証でOAuthは認可だ﹂などということが言われます。しかし、その言語の意味を取り違えている方が結構多い気がしています。﹁もうOpenIDなんていらね。OAuthだけでいいじゃん﹂というような言説がよく流れてくるのがその証拠だと思います。OAuth認証というのもその類ですね。
そこで、今日はOAuthとOpenIDの違いを考えてみたいと思います。
OpenIDは紹介状、OAuthは合鍵
まずはOpenIDの概要の復習です。﹁OpenIDは認証﹂という言葉の内容をまずは復習してみましょう。
﹁認証﹂とは大変広い言葉でいろいろな場面で使われますが、﹁OpenIDは認証﹂という使い方の時は、﹁OpenIDは、いま来ている人の身元を認証﹂︵ユーザ認証︶という意味です。図にすると図1のような流れになります。
この例では、有栖さんがお客としてサービス提供をしているサイトである伊部さんのところに行きます。
﹁伊部さん伊部さん、お宅のサービスを提供していただきたいのですが。﹂
﹁有栖さん、とおっしゃるのですね。申し訳ありませんが、本当に有栖さんなのかわからないので、宮来さんから紹介状をもらってきていただけませんか？紹介状にはメールアドレスも忘れずに。﹂
﹁わかりました。﹂
﹁宮来さん、お願いがあるのですが。﹂
﹁はい、なんでしょうか。﹂
﹁伊部さん向けにメールアドレス入の紹介状を書いていただきたいのですが。﹂
﹁有栖さん、わかりました。それではこれを持って行って下さい。﹂
﹁ありがとうございます。﹂
﹁伊部さん伊部さん、紹介状を持ってきました。﹂
﹁お、たしかに宮来さんの紹介状ですね。確かにあなたは有栖さんのようです。メアドもわかりました。では、サービスをご提供しましょう。﹂
こんなかんじです。伊部さんに対して有栖さんは自分が有栖であることを証明するために、紹介者(Identity Provider)宮来︵ぐうぐる︶さんに紹介状を書いてもらって、これを有栖さんは伊部さんに渡しています。伊部さんは、﹁宮来さんの紹介なら信用できるだろう﹂と考えて、有栖さんが本当に有栖和歌子さんだと認めてあげ、様々なサービスを提供します。
次にOAuthで認証をしていると呼ばれているような場合についてみてみましょう。
図2で﹁認証もどき﹂としたのは、本来ユーザ認証ではない行為を認証の代わりに使っているからです。ここでは伊部さんに対して、自分が有栖だということを証明するために、自分の表札がかかったマンションの部屋の合鍵を管理人(OAuth Server)の津逸田︵ついった︶さんに作ってもらって、それを伊部さんに渡しています。
﹁伊部さん伊部さん、お宅のサービスを提供していただきたいのですが。﹂
﹁有栖さん、とおっしゃるのですね。申し訳ありませんが、本当に有栖さんなのかわからないので、有栖さんの家の合鍵をいただけませんか？そしたら、部屋の中を見て有栖さんかどうか確かめるので﹂
﹁わかりました。﹂
﹁津逸田さん、お願いがあるのですが。伊部さんに渡す合鍵がほしいのです。﹂
﹁わかりました。ではこの鍵を渡して下さい。﹂
﹁ありがとうございました。﹂
﹁伊部さん、はい、合鍵です。﹂
﹁おお、ありがとうございます。﹂
伊部さんはこの合鍵で有栖さんの部屋に入って、
﹁ほほう、たしかに有栖さんの部屋に入れた。ということは、あなたは有栖さんだと認めてあげましょう。﹂
となって、有栖さんに様々なサービスを提供します。
OpenIDの時との大きな違いは、OpenIDの場合は単なる紹介状なので、伊部さんは悪さをしようと思っても、せいぜい有栖さんのメールアドレスを名簿屋さんに売るくらいしかできないのに対して、OAuthの場合は、伊部さんは有栖さんの家の中に入っていって、恋人とのラブレターのやり取りを﹁わーい、ラブレターみっけ。へー、こんな写真のやり取りしてるんだ。﹂と読んだり、モノを壊したり、有栖さんの友達に迷惑メールを撒き散らしたりやりたい放題にできるということです。え？そんなことは無いだろうって？いや、これ実際にTwitterのOAuth認証で起きたことですから1。DM読み放題になってたんですね。すぐに直しましたが。
有栖さんが伊部さんの事をよく知っていて、本当に信頼できるなら、それでも構いません。例えば、わたしの家では家の掃除をしてくれる方に合鍵を渡しています。これは、非常に便利なことですしまっとうなことです。しかし、よく知りもしないウェブサイトにOAuthで認証もどきをしてログインして回るというのは、そこら中に合鍵をばらまいて歩いていることになり、大変危険です。今も昔もOpenIDよりもOAuth認証をしたいというサイトが増えてきているのもなぜだかわかりますよね。合鍵をもらったほうがいろいろとサービス提供したり悪さをしたりするのに便利だからです。しかし、合鍵を持っている人がその家の居住者とは限りません。多くの場合は違います。ですので、﹁OAuth認証﹂はユーザ認証にはならないのです。
また、紹介状以外に、あとからその人が現在どういう状況にあるのかということを確認することもできるようにしています。これには、紹介状と一緒に、有栖さんの伊部さん向けの現況説明書のコピーだけが入っている伊部さん専用ロッカーの鍵︵アクセストークン︶をわたすことによって実現しています。この鍵を使って、伊部さんは必要に応じて有栖さんの現況を知ることができます。このロッカーのことを﹁UserInfo ︵ユーザ情報︶Endpoint﹂といいます。OAuthの保護リソースになります。これがあることによって、その場にユーザが居ないときでも、伊部さんは有栖さんの現況を知ることが得できるようになっています。
このように、OpenID ConnectではIDトークンを使って、今そこに来たユーザの認証情報を渡すとともに、後日、OAuthを使いながら安全に現況確認をできるようにしているのです。OpenID Connectは、OAuthの上のアイデンティティ層であると呼ばれるのはそういう理由からです。
サイトX, Y, Z は、OAuthの保護リソース(Protected Resources)にあたります。OpenID Connectでは、それぞれのサイトに伊部さんがアクセスするための鍵もUserInfo Endpoint に入っていて、伊部さんはこれを使ってこれらサイトにアクセスして最新の情報を取ってくることができます。
この例では、有栖さんがお客としてサービス提供をしているサイトである伊部さんのところに行きます。
﹁伊部さん伊部さん、お宅のサービスを提供していただきたいのですが。﹂
﹁有栖さん、とおっしゃるのですね。申し訳ありませんが、本当に有栖さんなのかわからないので、宮来さんから紹介状をもらってきていただけませんか？紹介状にはメールアドレスも忘れずに。﹂
﹁わかりました。﹂
﹁宮来さん、お願いがあるのですが。﹂
﹁はい、なんでしょうか。﹂
﹁伊部さん向けにメールアドレス入の紹介状を書いていただきたいのですが。﹂
﹁有栖さん、わかりました。それではこれを持って行って下さい。﹂
﹁ありがとうございます。﹂
﹁伊部さん伊部さん、紹介状を持ってきました。﹂
﹁お、たしかに宮来さんの紹介状ですね。確かにあなたは有栖さんのようです。メアドもわかりました。では、サービスをご提供しましょう。﹂
こんなかんじです。伊部さんに対して有栖さんは自分が有栖であることを証明するために、紹介者(Identity Provider)宮来︵ぐうぐる︶さんに紹介状を書いてもらって、これを有栖さんは伊部さんに渡しています。伊部さんは、﹁宮来さんの紹介なら信用できるだろう﹂と考えて、有栖さんが本当に有栖和歌子さんだと認めてあげ、様々なサービスを提供します。
次にOAuthで認証をしていると呼ばれているような場合についてみてみましょう。
図2で﹁認証もどき﹂としたのは、本来ユーザ認証ではない行為を認証の代わりに使っているからです。ここでは伊部さんに対して、自分が有栖だということを証明するために、自分の表札がかかったマンションの部屋の合鍵を管理人(OAuth Server)の津逸田︵ついった︶さんに作ってもらって、それを伊部さんに渡しています。
﹁伊部さん伊部さん、お宅のサービスを提供していただきたいのですが。﹂
﹁有栖さん、とおっしゃるのですね。申し訳ありませんが、本当に有栖さんなのかわからないので、有栖さんの家の合鍵をいただけませんか？そしたら、部屋の中を見て有栖さんかどうか確かめるので﹂
﹁わかりました。﹂
﹁津逸田さん、お願いがあるのですが。伊部さんに渡す合鍵がほしいのです。﹂
﹁わかりました。ではこの鍵を渡して下さい。﹂
﹁ありがとうございました。﹂
﹁伊部さん、はい、合鍵です。﹂
﹁おお、ありがとうございます。﹂
伊部さんはこの合鍵で有栖さんの部屋に入って、
﹁ほほう、たしかに有栖さんの部屋に入れた。ということは、あなたは有栖さんだと認めてあげましょう。﹂
となって、有栖さんに様々なサービスを提供します。
OpenIDの時との大きな違いは、OpenIDの場合は単なる紹介状なので、伊部さんは悪さをしようと思っても、せいぜい有栖さんのメールアドレスを名簿屋さんに売るくらいしかできないのに対して、OAuthの場合は、伊部さんは有栖さんの家の中に入っていって、恋人とのラブレターのやり取りを﹁わーい、ラブレターみっけ。へー、こんな写真のやり取りしてるんだ。﹂と読んだり、モノを壊したり、有栖さんの友達に迷惑メールを撒き散らしたりやりたい放題にできるということです。え？そんなことは無いだろうって？いや、これ実際にTwitterのOAuth認証で起きたことですから1。DM読み放題になってたんですね。すぐに直しましたが。
有栖さんが伊部さんの事をよく知っていて、本当に信頼できるなら、それでも構いません。例えば、わたしの家では家の掃除をしてくれる方に合鍵を渡しています。これは、非常に便利なことですしまっとうなことです。しかし、よく知りもしないウェブサイトにOAuthで認証もどきをしてログインして回るというのは、そこら中に合鍵をばらまいて歩いていることになり、大変危険です。今も昔もOpenIDよりもOAuth認証をしたいというサイトが増えてきているのもなぜだかわかりますよね。合鍵をもらったほうがいろいろとサービス提供したり悪さをしたりするのに便利だからです。しかし、合鍵を持っている人がその家の居住者とは限りません。多くの場合は違います。ですので、﹁OAuth認証﹂はユーザ認証にはならないのです。
OAuthで正しく認証するには～OpenID Connect
さて、例えば twitter の OAuth で﹁認証もどき﹂をするのは大変危険だということはおわかりいただけたと思います。正しく認証だけをするには、紹介状を使うのが良いということになります。この紹介状のことをOpenID Connect(OIDC)ではIDトークンといいます。 IDトークンには様々な情報を書くことができます。その人の名前やメールアドレスなどの他に、このユーザが実際にいつどのような身元確認︵運転免許証を使って誰がいつどのような根拠に基づいてなど︶をしたのか、ユーザ認証︵SMS認証、パスキーなど︶をしたのかなども書き入れて送ることができます。こうした﹁どういう確認をしたのか﹂というのは、本人についての情報というより、本人の身元確認やユーザ認証についての情報︵メタデータ︶です。これらがわからないと、そのユーザ認証の安全度が実はわかりません。そこで、OpenID Connect では、こうしたことも合わせて紹介状にして送ることができるようにしているのです。これが、図3の手続き4までの流れです。
また、紹介状以外に、あとからその人が現在どういう状況にあるのかということを確認することもできるようにしています。これには、紹介状と一緒に、有栖さんの伊部さん向けの現況説明書のコピーだけが入っている伊部さん専用ロッカーの鍵︵アクセストークン︶をわたすことによって実現しています。この鍵を使って、伊部さんは必要に応じて有栖さんの現況を知ることができます。このロッカーのことを﹁UserInfo ︵ユーザ情報︶Endpoint﹂といいます。OAuthの保護リソースになります。これがあることによって、その場にユーザが居ないときでも、伊部さんは有栖さんの現況を知ることが得できるようになっています。
このように、OpenID ConnectではIDトークンを使って、今そこに来たユーザの認証情報を渡すとともに、後日、OAuthを使いながら安全に現況確認をできるようにしているのです。OpenID Connectは、OAuthの上のアイデンティティ層であると呼ばれるのはそういう理由からです。
分散クレームと集約クレーム
分散クレーム
この伊部さん専用のロッカーには、有栖さんの現況が書いてある紙が入っているだけでなく、伊部さんにわたしたい他のものも入れておくことができます。例えば、第三者からもらった資格証明書だとか、他のロッカーの鍵などです。伊部さんはそうやって取り出した鍵を使って、他のロッカーに行って、そこに入れてある情報を取り出したりもできます。図4は、この関係を表しています。 このように、他のロッカーにある情報を取りに行くモデルのことをOpenID Connectでは分散クレーム︵Distributed Claims︶といいます。﹁クレーム﹂というと聞き慣れない言葉で、日本語では﹁文句﹂みたいに聞こえたりもしますが、英語にはそのようなニュアンスはなく﹁主張﹂という意味しかありません。ここではそれぞれの属性をそれぞれのサイトが正しいと主張している値ということで﹁クレーム﹂と呼んでいます。紹介状ってそういうものですよね。
サイトX, Y, Z は、OAuthの保護リソース(Protected Resources)にあたります。OpenID Connectでは、それぞれのサイトに伊部さんがアクセスするための鍵もUserInfo Endpoint に入っていて、伊部さんはこれを使ってこれらサイトにアクセスして最新の情報を取ってくることができます。
集約クレーム
一方では、集約クレーム(Aggregated Claims)という方式もあります。図5がこれをあらわしています。ここでは、UserInfo Endpointが、サイトX, Y, Z に事前に有栖さんが取得しておいた鍵︵アクセストークン︶でアクセスしてクレームを取ってきて、それを集約して伊部さんに返します。
まとめ
というわけで、まとめです。 OpenID Connectは、OAuthを使って安全にユーザ認証を行うだけでなく、インターネット上に散在する様々な情報をやりとりしたり、サービス提供を可能にする分散アイデンティティアーキテクチャです。2023年現在、ネットを使っている人でOpenID Connectを使っていない人はほぼ居ないと言われるほど普及しています。﹁Appleでサインイン﹂も﹁Googleサインイン﹂も﹁マイクロソフトサインイン﹂もみなOpenID Connectです。﹁インターネットのアイデンティティ層︵レイヤー︶﹂というキャッチフレーズもあながち嘘ではないのです。 更新履歴- 初版: 2011年5月15日 6:05 PM
- 第2版: 2023年6月8日 1:00 AM
- 第2.1版 2023年6月8日 11:10 AM
関連記事
- デジタル庁認証アプリ FIRST IMPRESSION まとめ
- ナショナルオーストラリア銀行の円卓会議で開会の辞を行いました
- EUデジタルアイデンティティウォレットのリファレンス実装が公開されました
- 「Trusted Web の実現に向けたユースケース実証事業」の『株式会社電通国際情報サービス:「KYC/KYBに基づいたトラストのある取引」を促進する新しい仕組み』というOpenID4VCを使った取り組みの最終報告に有識者として法制面および技術面に関するコメントを提供しました
- 『Web3の未解決問題』は本日(2/29)発売です。「SBT」「DID」「分散の誤謬」が入っていますKindle版はすぐダウンロードできます。紙版はBGINに持ってきていただければ、わたしや松尾先生の署名ももらえるかも！
- [拡散希望] OpenIDの25年Youtube配信〜粘るは金・金は粘りの素
- OpenID Summit Tokyo 2024
- Youtube日本語チャネルの登録者数がようやく1000人になりました。これまで待っていたこととか…今後の予定とか…
- 非技術者のためのOAuth認証(?)とOpenIDの違い入門【2023年版】
- OpenWallet Foundationが発足しました
うぉぉ。非技術者なのでめちゃくちゃわかりやすかった。
解りやすい解説、有り難うございます！
ちょうどOpenIDConnectについて調べ物していたので、わかりやすくてよかったです！