OAuthがソーシャルログインで使われるようになった経緯
最近の僕の趣味は、stack overflowに来た質問に回答を付ける、ということです。特に本家英語版の方では、英語の読み取りと作文の練習をかねてやってます。もちろん、日本語版の方でも、回答できそうな質問が来たら、積極的に回答するようにしています。たまに間違えた回答付けてしまって-1をもらうこともありますが、それを含めての貢献かな、と。気にしない気にしない。
さて、日本語版の方でOAuthに関する以下の質問が来ていました。
OAuthはどのようにしてソーシャルログインとして使用されるようになったのでしょうか？
下記の記事をみるとOAuthはもともと外部からAPIを呼ぶためのものであり、ソーシャルログインとして使うのはHack的な使い方のような印象をうけました。
本来の目的が、ソーシャルログインのためでないならどのような経緯(どこどこのサービスで使われたのがきっかけというような歴史）でソーシャルログインとして使用されるように浸透していったのでしょうか？（もともとソーシャルログインとしても使うことが想定されていたのでしょうか？）
なかなか興味深い質問だったので、僕の認識を回答してみました。以下がそのコピーです。せっかくなので、このブログエントリにも残しておこうかな、と。
はっきりと答えることが難しい質問ですね。歴史的経緯として僕が思っていることを答えてみたいと思います。
まず、ユーザ認証のためのプロトコル（OpenIDとか）と、認可のためのプロトコル（OAuthとか）は、明確に分けて説明されることが普通です。これらに詳しい人であればあるほど、区別して説明したがりますので。OAuthを「認証のため」とか言うと過剰反応する人もいるでしょう。ただし、OAuthを提供する側と、それを利用する側で、「認証」という行為についての捉え方は大きく異なります。
OAuth1.0が登場した背景には、Facebook PlatformやOpenSocialといった「ソーシャルアプリ（特にソーシャルゲーム）」の流行とセットで考えると良いかと思います。ソーシャルアプリは「そのアプリを利用するユーザの情報と、そのユーザの友だち達の情報」を扱うことが当時非常に画期的であり、あっという間に広まっていきました。それを支え続けたプロトコルが、OAuth1.0, OAuth1.0a, そしてOAuth2だと思います。ソーシャルアプリは、まずそれを利用しようとしているユーザが誰なのか特定して、そのユーザの情報をProfile APIなどで取得します。さらに、そのユーザの友だち一覧をFriend list APIを使って取得し、友だちのキャラを画面上に登場させたり、友だちランキングを作って自分が何位なのか提示して競わせたりしたわけです。
例えば、「自分のタイムラインにフィードを投稿するAPI」を考えてみます。OAuthによる手順によって、アクセストークンが発行されます。このアクセストークンを使ってそのAPIを叩けば、その認可ユーザのタイムラインにフィード投稿が実際に行われます。この際、そのAPIを叩くClientは、「その認可ユーザは誰なのか」知らなくても、アクセストークンによってAPI提供側は「誰が」はわかるので、やりたいことは成り立ちます。まさに「認可」だけを使ったケースです。
しかし、ソーシャルアプリでは、「認可ユーザの情報」を積極的に使います。そのユーザのID、ニックネーム、プロフィール画像のURLなどをProfile APIで取得して、ソーシャルアプリ内にキャラを仕立てるわけです。この「認可された結果のアクセストークンを使ってProfile APIによりユーザID（およびユーザ属性情報）を取得すること」は、まさにソーシャルアプリ側から見たら「ユーザ認証を行っている」ことになります。つまり、
- OAuthの利用用途のほとんどは、ソーシャルアプリである。
- ソーシャルアプリのほとんどは、利用者のユーザ認証を必要とする。
- OAuthの結果得られるアクセストークンとProfile APIを使って、ユーザ情報を取得できる。
という条件から、ソーシャルアプリの文脈が暗黙的になって、「OAuthは（ユーザ）認証のプロトコルである」という言われ方をしてしまったのかな、と僕は思っています。OAuthの利用側から見たら、OAuth+Profile APIによってユーザ認証していることになりますし、そういう言われ方をしてしまうことも仕方ないのかな、という感じです。そして、時は流れて、Friend list APIなど他のAPIを使わずに、OAuth+Profile APIのみ利用するアプリも増えてきました。そういった流れから、「OAuthがソーシャルログインとして使用される」という状況が増えたのだと思います。
ただし、OAuth提供側からすると、OAuthプロトコルを実装する上で「OAuth提供側がユーザを特定するための仕組み」については言及がありません。OAuthを提供するAというサービスは、他の事業者が提供しているOpenIDや自社の独自手順によるユーザ認証などを同時に組み込んでも問題無いわけです。よって、「ユーザ認証手順は含まない＝認証のためのプロトコルではない」という言われ方につながっています。つまり、立場によって違うわけです。
OpenID Foundationの中の人達もこの状況をよく見ていて、「OAuthをHackしてユーザ認証している」という違和感を払拭するため（これは僕の想像です）に、OAuth+Profile APIを参考にして、結局OAuth2の上でユーザ認証手順を再定義しました（OpenID Connect）。そして、主要なOAuth提供事業者達は、OAuth2の上にOpenID Connectを実装し提供し始めた、で今日に至ります。
