昔から、「OpenIDは認証でOAuthは認可だ」などということが言われます。しかし、その言語の意味を取り違えている方が結構多い気がしています。「もうOpenIDなんていらね。OAuthだけでいいじゃん」というような言説がよく流れてくるのがその証拠だと思います。
そこで、今日はOAuthとOpenIDの違いを考えてみたいと思います。
OpenIDは紹介状、OAuthは合鍵
まずはOpenIDの復習です。「OpenIDは認証」という言葉の内容をまずは復習してみましょう。
「認証」とは大変広い言葉でいろいろな場面で使われますが、「OpenIDは認証」という使い方の時は、「OpenIDは、いま来ている人の身元を認証」という意味です。図にすると次のような流れになります。
図 1 OpenID認証(身元確認)の場合
この図では、伊部さん(サイト)に対して有栖さんは自分が有栖であることを証明するために、公証人(Identity Provider)グーグルに紹介状を書いてもらっています。伊部さんは有栖さんのメールアドレスも必要なので、紹介状にはそれも書いてあります。これを有栖さんは伊部さんに渡しています。伊部さんは、「グーグルさんの紹介なら信用できるだろう」と考えて、有栖さんが本当に有栖和歌子さんだと認めてあげ、様々なサービスを提供します。
次にOAuthで認証をしていると呼ばれているような場合についてみてみましょう。
図 2 OAuthで身元確認もどきをする場合
図2で「認証もどき」としたのは、本来認証ではない行為を認証の代わりに使っているからです。ここでは伊部さんに対して、自分が有栖だということを証明するために、自分の表札がかかったマンションの部屋の合鍵を管理人(OAuth Server)ツイッターさんに作ってもらって、それを伊部さんに渡しています。伊部さんはこの合鍵で有栖さんの部屋に入って、「ほほう、たしかに有栖さんの部屋に入れた。ということは、あなたは有栖さんだと認めてあげましょう。」となって、有栖さんに様々なサービスを提供します。
OpenIDの時との大きな違いは、OpenIDの場合は単なる紹介状なので、伊部さんは悪さをしようと思っても、せいぜい有栖さんのメールアドレスを名簿屋さんに売るくらいしかできないのに対して、OAuthの場合は、伊部さんは有栖さんの家の中に入っていって、恋人とのラブレターのやり取りを読んだり、モノを壊したり、有栖さんの友達に迷惑メールを撒き散らしたりやりたい放題にできるということです。有栖さんが伊部さんの事をよく知っていて、本当に信頼できるなら、それでも構いません。例えば、わたしの家では、家の掃除をしてくれる方に合鍵を渡しています。これは、非常に便利なことですしまっとうなことです。しかし、よく知りもしないウェブサイトにOAuthで認証もどきをしてログインして回るというのは、そこら中に合鍵をばらまいて歩いていることになり、大変危険です。最近はOpenIDよりもOAuth認証をしたいというサイトが増えてきているのもなぜだかわかりますよね。合鍵をもらったほうがいろいろとサービス提供したり悪さをしたりするのに便利だからです。
OAuthで正しく認証するには~OpenID Connect
さて、例えば twitter の OAuth で「認証もどき」をするのは大変危険だということはおわかりいただけたと思います。では、OAuthで正しく認証だけをするにはどうしたら良いのでしょうか?例えば、部屋の鍵の代わりに、紹介状のコピーだけが入っているロッカーの鍵を渡すことにしてはどうでしょうか?
これならば、取られていってもせいぜい紹介状だけです。被害はOpenIDの時と大差ありません。
実は、これが次世代OpenIDである「OpenID Connect」 (ABワーキンググループで作られていたものに、Connectという名前をつけることにしました)の基本にあるアイディアです。このロッカーのことを、「UserInfo (ユーザ情報)Endpoint」といいます。つまり、OAuthを使いながら、安全に身元確認をできるようにしているのです。OpenID Connectは、OAuthの上のアイデンティティ層であると呼ばれるのはそういう理由からです。
もっとも、これだけだとそのユーザについての情報がわかるだけで、このユーザが実際にいつどのような認証(ワンタイムパスワード、電子証明書、など)をしたのかがわかりません。こうした「どういう認証(身元確認)をしたのか」というのは、本人についての情報というより、本人の身元確認についての情報(メタデータ)です。これらがわからないと、その認証の安全度が実はわかりません。そこで、OpenID Connect では、UserInfoロッカーの鍵と一緒に、何時どういう認証をしたのかということも合わせて紹介状にして送ります。この紹介状のことを、OpenIDトークンといいます。
図 3 OpenID Connectの場合
ここで渡される鍵は、伊部さん専用のロッカーの鍵です。その伊部さん専用のロッカーには、有栖さんの基本情報が書いてある紙が入っています。また、そこには伊部さんにわたしたい他のものも入れておくことができます。例えば、第三者からもらった資格証明書だとか、他のロッカーの鍵などです。伊部さんはそうやって取り出した鍵を使って、他のロッカーに行って、そこに入れてある情報を取り出したりもできます。
図 4 OpenID Connectのクレーム集約、分散クレーム
サイトX, Y, Z にアクセスする方法はOAuthのResource Access と呼ばれるものと同じものです。しかし、普通のOAuthと大きな違いがあります。それは、鍵の発行の仕方です。OAuthでは、それぞれのサイトの鍵を発行するのはそれぞれのサイトです。しかし、OpenID Connectでは、それぞれのサイトの鍵もUserInfo Endpoint が発行しています。逆に言えば、サイトX,Y,Zは、UserInfo Endpointの発行した鍵を受け入れられるようになっています。そのためには、それぞれのサイトは(1) この鍵の発行者を信頼(トラスト)し、(2)この鍵の正統性を確かめられるようになっていなければなりません。これを実現するために、OpenID Connectでは、JSON Web Token という鍵(Access Token)の形式を利用しています。暗号を使って(1)(2)を実現しているのですが、これはまた別の機会に譲りたいと思います。
というわけで、まとめです。
OpenID Connectは、OAuthを使って安全に認証を行うだけでなく、インターネット上に散在する様々な情報をやりとりしたり、サービス提供を可能にする分散アイデンティティアーキテクチャなのです。
(ベルリンにて)
関連記事
- 「最高にエモい」と好評だったOpenID Summit Tokyoクロージング・キーノート 「No ID, No DX」の録画が一般公開されました
- ChatGPTに欽定訳聖書のスタイルでIDトークンとアクセストークンを説明させてみた
- ChatGPTにOpenIDを説明させてみた
- gBizIDどストライク案件:twitter社、企業による担当者認証を近日始めるとのこと
- 中央集権IDから分散IDに至るまで、歴史は繰り返す | 日経クロステック
- Identiverse: Where are we with SIOP and DID?
- [2020-09-22]FDX Global Summit キーノート
- [2020-09-17] Citi Talks on Payments に出演しました
- リモート・ワークだと、24時間戦えますかになる件〜5/22に、OpenID Foundation Virtual Workshopに出演しました。
- Open Banking Conformance & Certification Workshop
うぉぉ。非技術者なのでめちゃくちゃわかりやすかった。
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について調べ物していたので、わかりやすくてよかったです!