セキュリティ

OAuth2.0とOpen ID Connectについて

はじめに

Open ID Connectについて、いまいち存在意義を理解できていなかったため整理しました。
なお、思いっきり簡略化しています。
間違いを見つけた方はコメントかtwitterで指摘をお願いします。

OAuth2.0の基本

まず、OAuth2.0は「認証」ではなく「認可」のためのプロトコルです。
では、「認可」とは何か、と言うことになりますが、認可の説明は他のサイトに譲るとして、OAuth2.0で認可を提供する具体例を見てみます。
右の図は、Twitterで誰かからフォローされた時に、自動でフォローし返すwebアプリを利用する、と言う状態を想定しています。
このようなwebアプリを利用する時、ユーザーはOAuth2.0を利用して、webアプリに「フォローしているユーザー一覧を取得する」と言う権限と、「フォローを行う」と言う権限を渡します。
すると、webアプリは提供された権限を利用して「ユーザー一覧を取得し、新しいフォローワーがいればフォローする」という作業を定期的に実行します。
この時、webアプリはユーザーがログインしてTwitterを利用しているかどうかに関わらず、この作業を実行することができます。

つまり、「自分以外に権限を与えることで、自分のエージェント(代理人)として動作させるためのプロトコル」がOAuth2.0であると言えます。

OAuth2.0をログインに利用するということ

上記のように、OAuth2.0は「自分以外に権限を与えることで、自分のエージェント(代理人)として動作させるためのプロトコル」ですから、「ログイン」と言う動作とは本質的にはまったく関係がありません。
では、なぜログインにOAuth2.0が利用されているのでしょうか。
右の図は、OAuth2.0を利用してログインすることを簡単に表してみた図です。
この図でログイン対象となるwebサイトは、ユーザーに対してOAuth2.0で何等かの権限を要求します。その要求に対し、権限を提供できた場合、「権限を提供することができるのだから本人に違いない」と判断してwebサイトにログインさせています。
つまり、「OAuth2.0は権限を提供するためのプロトコルだけど、権限を提供できるのだから提供してきた人はきっと本人だよね」と言う前提に立ち、本来の用途とは異なる用途に利用しているわけです。

OAuth2.0をログインに利用する時の問題

ですが、「OAuth2.0は権限を提供するためのプロトコルだけど、権限を提供できるのだから提供してきた人はきっと本人だよね」と言う前提は、実は間違っています。
OAuth2.0は権限を提供するためのプロトコルであるため、「権限を提供できるのだから提供してきた人はきっと本人」ではなく、「権限を提供できるのはその権限を保有している何か」であることしか保証されません。
そして、自動でフォローを行うwebアプリのような、権限を提供された代理人(エージェント)も「その権限を保有している何か」に含まれます。そのため、このような権限を提供された代理人(エージェント)もログインすることができてしまうのです。
普通のwebアプリ/webサイトはそのように他の用途に流用することはまずありえませんが、悪意を持ったwebアプリが存在した場合、そのwebアプリを利用したユーザーに成りすましてログインすることができてしまいます。

Open ID Connectについて

では、Open ID Connectは何なのかと言うと、「権限の提供を行う時に本人確認を行う機能をOAuth2.0に追加」するプロトコルです。
つまり、Open ID Connectを利用することで、「今、権限を提供してきたのは本人なのか」を確認することができるわけです。
そのため、Open IC Connectもログインのために利用するプロトコルではありませんが、「本人であること」が保証されているため、ログインに使用しても問題ないと言えます。