質問: 下記の記事をみると`OAuth`はもともと外部からAPIを呼ぶためのものであり、ソーシャルログインとして使うのはHack的な使い方のような印象をうけました。 本来の目的が、ソーシャルログインのためでないならどのような経緯(どこどこのサービスで使われたのがきっかけというような歴史)でソーシャルログインとして使用されるように浸透していったのでしょうか?(もともとソーシャルログインとしても使うことが想定されていたのでしょうか?) 参考 -- デジタル・アイデンティティ技術最新動向(1):「OAuth」の基本動作を知る (1/2) - @IT > > ひと言でいうとOAuthは、 > > > あるサービス(サービスA)上にエンドユーザーが所有するリソースや、そのエンドユーザーがアクセス権限を持つサービスAの各種機能に対し、 > > エンドユーザーの許可を受けたほかのサービス(サービスB)がアクセスする ために > > > エンドユーザーがサービスBに対して許可を与え サービスBがサービスAの提供するAPIにアクセスする際に許可を受けていることを証明する > > という一連のフローを、セキュアに実現することを目的とした「アクセス権限の付与」のためのプロトコルです。 > > > 第1回 OAuthとは?―OAuthの概念とOAuthでできること:ゼロから学ぶOAuth|gihyo.jp ... 技術評論社 > > OAuthとは > > > OAuthは,以下の特徴を持つ「認可情報の委譲」のための仕様です。 > > > あらかじめ信頼関係を構築したサービス間で ユーザの同意のもとに セキュアにユーザの権限を受け渡しする > > >
回答: はっきりと答えることが難しい質問ですね。歴史的経緯として僕が思っていることを答えてみたいと思います。 まず、ユーザ認証のためのプロトコル(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を実装し提供し始めた、で今日に至ります。