昔から、「OpenIDは認証でOAuthは認可だ」などということが言われます。しかし、その言語の意味を取り違えている方が結構多い気がしています。「もうOpenIDなんていらね。OAuthだけでいいじゃん」というような言説がよく流れてくるのがその証拠だと思います。OAuth認証というのもその類ですね。
そこで、今日はOAuthとOpenIDの違いを考えてみたいと思います。
OpenIDは紹介状、OAuthは合鍵
まずはOpenIDの概要の復習です。「OpenIDは認証」という言葉の内容をまずは復習してみましょう。
「認証」とは大変広い言葉でいろいろな場面で使われますが、「OpenIDは認証」という使い方の時は、「OpenIDは、いま来ている人の身元を認証」（ユーザ認証）という意味です。図にすると図1のような流れになります。
この例では、有栖さんがお客としてサービス提供をしているサイトである伊部さんのところに行きます。
「伊部さん伊部さん、お宅のサービスを提供していただきたいのですが。」
「有栖さん、とおっしゃるのですね。申し訳ありませんが、本当に有栖さんなのかわからないので、宮来さんから紹介状をもらってきていただけませんか？紹介状にはメールアドレスも忘れずに。」
「わかりました。」
「宮来さん、お願いがあるのですが。」
「はい、なんでしょうか。」
「伊部さん向けにメールアドレス入の紹介状を書いていただきたいのですが。」
「有栖さん、わかりました。それではこれを持って行って下さい。」
「ありがとうございます。」
「伊部さん伊部さん、紹介状を持ってきました。」
「お、たしかに宮来さんの紹介状ですね。確かにあなたは有栖さんのようです。メアドもわかりました。では、サービスをご提供しましょう。」
こんなかんじです。伊部さんに対して有栖さんは自分が有栖であることを証明するために、紹介者(Identity Provider)宮来（ぐうぐる）さんに紹介状を書いてもらって、これを有栖さんは伊部さんに渡しています。伊部さんは、「宮来さんの紹介なら信用できるだろう」と考えて、有栖さんが本当に有栖和歌子さんだと認めてあげ、様々なサービスを提供します。
次にOAuthで認証をしていると呼ばれているような場合についてみてみましょう。
図２で「認証もどき」としたのは、本来ユーザ認証ではない行為を認証の代わりに使っているからです。ここでは伊部さんに対して、自分が有栖だということを証明するために、自分の表札がかかったマンションの部屋の合鍵を管理人(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の手続き４までの流れです。
また、紹介状以外に、あとからその人が現在どういう状況にあるのかということを確認することもできるようにしています。これには、紹介状と一緒に、有栖さんの伊部さん向けの現況説明書のコピーだけが入っている伊部さん専用ロッカーの鍵（アクセストークン）をわたすことによって実現しています。この鍵を使って、伊部さんは必要に応じて有栖さんの現況を知ることができます。このロッカーのことを「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)という方式もあります。図５がこれをあらわしています。ここでは、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
関連記事
[catlist name=”oauth,openid”]
脚注
@_Nat Zoneをもっと見る
購読すると最新の投稿がメールで送信されます。
うぉぉ。非技術者なのでめちゃくちゃわかりやすかった。
Twitter の OAuth が権限をこまかくあたえられないのは、Twitter の問題であって、OAuth の問題ではありませんよね?
一般的な OAuth サーバーは、権限をこまかくあたえられるようになっているのが普通かとおもいます。たえば facebook, mixi などはそうなっています。基礎的なプロフィールの閲覧のみをおこなえるように権限を付与することが可能ですよね? その場合、認証がわりにつかっても問題はないのではないでしょうか。
とくに Nat さんは OpenID Foundation の理事長という肩書をおもちなので、この記事は、OpenID Connect を宣伝するために、OAuth にたいする FUD をおこなっているようにみえますが、この点についてはどのようにおかんがえでしょうか。
よく読んでいただければおわかりになると思いますが、この文書の目的は、認証と認可の違いをきちんと認識してもらうことにあります。そのことを明確に感じることができるように、Twitter のOAuth認証の例を出して、安易に認可を認証の代わりに使うとまずいことを実感してもらっています。その上で、認可のフレームワークを認証に使うならば、Scopeをまずはよく考えるべき（現在はあまりに広く権限を与えすぎる傾向にある）、さらにそのScopeは標準化されるべきであろうと言っています。また、認証として使うのにはそれだけでは実は十分でなく、いわゆる認証コンテキストも必要になってきます。これの表現も標準化しないと、非常に不便なことになります。また、分散系として機能するためには、標準化された識別子体系も必要になります。OpenID ConnectはこれらをOAuthのExtensionとして実現するためのものです。
上記のとおり、OpenID Connect はOAuth 2.0のExtensionです。OAuthに対するFUDを行うインセンティブはありません。自分の足を撃つことになりますから。
立場的な話で言えば、私はOpenID Foundation の Chairですが、同時にOAuth2.0のContributorのひとりです。OAuth 2.0の著者のEranもDickもDavidもよく知っていますし（←EranはXRD1.0を一緒につくりました。Dick, DavidはOpenID Foundationで一緒です)、OAuth 2.0 Bearer Token の著者のMike (JWT, Connectを一緒に書いています）もよく知っています。その意味からもOAuthを貶める意味はありません。
安易にOAuthを認証に使うべからずというのは、しかしFUDでも何でもなく事実であろうかと思います。ちゃんとそのあたりをしていかないと、そのうちOAuth自体にダメプロトコルの烙印が押されてしまいます。それは避けなければなりません。
解りやすい解説、有り難うございます！
ちょうどOpenIDConnectについて調べ物していたので、わかりやすくてよかったです！