2007年9月5日、Eran Hammer-Lahav氏によって公開されたExplaining OAuthを参考に改編
OAuthは2006年11月頃、Blaine Cook氏がTwitterのOpenID実装に取り組んでいた際に始まりました。彼は、認証を委任するためにOpenIDとTwitterのAPIを連携させる方法を探し、Chris Messina氏に連絡を取りました。彼らはCitizenSpace OpenIDミーティングでDavid Recordon氏、Larry Halff氏らと会い、既存のソリューションについて議論しました。Larry氏はMa.gnolia Dashboard WidgetsへのOpenID統合を検討していました。既存のOpenID機能と他の業界慣習を検討した結果、APIアクセス委任のためのオープンスタンダードが存在しないという結論に至りました。この議論は数ヶ月間オンラインとオフラインで続けられました。
2007年4月、オープンなプロトコルの提案を作成するために、少数の開発者グループでGoogleグループが作成されました。この問題はOpenID特有のものではなく、GoogleのDeWitt Clinton氏がこのプロジェクトの噂を聞きつけ、利害関係者としてだけでも支援する意思を表明しました。2007年7月、チームは最初の仕様を起草し、グループは貢献に関心のある誰でも参加できるようになりました。2007年10月3日、OAuth Core 1.0最終ドラフトが公開されました。
今日の高級車には、多くの場合、バレーキーが付属しています。これは駐車場係に渡す特別なキーで、通常のキーとは異なり、車を1〜2マイル以上走行させることはできません。バレーキーによってはトランクが開かなかったり、車載の携帯電話アドレス帳へのアクセスがブロックされたりするなど、制限が設けられています。バレーキーがどのような制限を課すかに関わらず、このアイデアは非常に巧妙です。通常のキーを使用してすべてをロック解除しながら、特別なキーを使用して車へのアクセスを制限することができます。
毎日、他のサイトの機能を組み合わせたサービスを提供する新しいウェブサイトが立ち上がっています。オンラインの写真を印刷する写真ラボ、アドレス帳を使用して友達を探すソーシャルネットワーク、そして人気のサイトの独自のデスクトップアプリケーションバージョンを構築するためのAPIなどです。これらはすべて素晴らしいサービスですが、一部の実装における問題点は、他のサイトへのユーザー名とパスワードの要求です。秘密の資格情報を共有することに同意すると、パスワードを他人(オンラインバンキングにも使用しているのと同じパスワード)に公開するだけでなく、彼らが望むことを何でもする完全なアクセス権を与えることになります。彼らは何でもできます—パスワードを変更してあなたを締め出すことさえできます。
これがOAuthが解決する問題です。OAuthにより、ユーザーは、あるサイト(サービスプロバイダーと呼ばれる)にある自分のプライベートリソースへのアクセスを、別のサイト(コンシューマーと呼ばれ、ユーザーと混同しないでください)に許可することができます。OpenIDは、多くのサイトに単一のアイデンティティを使用してサインインすることですが、OAuthは、アイデンティティ(またはその秘密の部分)をまったく共有せずに自分のものへのアクセス権を与えることです。
OAuthはOpenIDの拡張機能ではなく、仕様レベルではOpenIDと共通しているのは、一部の共通の著者と、どちらも認証とアクセス制御の分野におけるオープンな仕様であるという事実だけです。「なぜOAuthはOpenIDの拡張機能ではないのか?」は、おそらくグループで最も頻繁に質問される質問です。答えは簡単です。OAuthは、ユーザーにパスワード(およびその他の資格情報)を公開することを強制することなく、開発者がAPIを介してサービスを提供するための標準的な方法を提供しようと試みています。OAuthがOpenIDに依存していた場合、OpenIDサービスのみがそれを利用できるようになり、OpenIDは優れていますが、それを使用できないか望ましくない多くのアプリケーションがあります。これは、2つを一緒に使用できないという意味ではありません。OAuthはユーザーにアクセス権限を与えることについて話し合い、OpenIDはユーザーが実際に彼らが言っている人であることを確認することについて話し合います。それらはうまく連携するはずです。
みんなです。ウェブ開発者であれば、あなたもそう願っています。
いいえ。OAuthは、多くの確立された業界プロトコルの標準化と統合された知恵です。これは、現在使用されている他のプロトコル(Google AuthSub、AOL OpenAuth、Yahoo BBAuth、Upcoming API、Flickr API、Amazon Web Services APIなど)と似ています。各プロトコルは、ユーザー資格情報をアクセストークンまたはチケットと交換するための独自のメソッドを提供します。OAuthは、これらのプロトコルそれぞれを注意深く研究し、ベストプラクティスと共通点を抽出して、新しい実装と、既存のサービスがOAuthをサポートするためのスムーズな移行を可能にすることによって作成されました。
OAuthが他のプロトコルやサービスよりも進化している分野の1つは、非ウェブサイトサービスの直接的な処理です。OAuthは、デスクトップアプリケーション、モバイルデバイス、セットトップボックス、そしてもちろんウェブサイトへのサポートを組み込んでいます。今日の多くのプロトコルは、ソフトウェアにハードコードされた共有シークレットを使用して通信しており、プライベートデータにアクセスしようとするサービスがオープンソースの場合、問題になります。