Abstract OAuth Core 1.0 defines a protocol for delegating user access to Consumer applications without sharing the user's private credentials. Some consumer applications use the RSA_SHA1 signature method. To verify RSA_SHA1 signatures, Service Providers need to be in possession of an authentic copy of the consumer application's public key. Whenever a consumer application changes the private key it

OAuth Consumer Request 前回も簡単に触れましたが、OAuth Consumer Requestという拡張仕様があり、 これは二者間でのやり取りを行うためのものでした。OAuthのプロトコル中で 重要なパラメータは、トークンとシグネチャ(署名)です。トークンは、ある エンドユーザーがサービスプロバイダ上に持っているリソースに対して、 特定のコンシューマがアクセスしてもよいという認可を与えたという証明となります。 また、コンシューマはリクエスト毎に共有鍵、もしくは秘密鍵で署名をつけることにより、 不正なコンシューマの偽装を防ぐことが出来ます。 二者間でやりとりを行う場合、エンドユーザは登場しません。なので、トークンを 扱う必要がなく、署名の検証のみで認証を行うことになります。 事前にリクエストトークンの発行、エンドユーザをリダイレクトさせて承認をもらう、 承認済のリクエス

クロスドメインでのデジタルアイデンティティを守る APIアクセス権を委譲するプロトコル、 OAuthを知る 作島　立樹 NRIパシフィック 2008/1/21 OAuthプロトコルを知る OAuthを使ったWeb APIアクセス権の委譲が実際にどのように行われるかはエラン・ハマー氏のブログに詳しいが、簡単に説明すると、2つのアプリケーションをマッシュアップさせたい「ユーザー」が、リソース（例えば、アルバムサイトにある写真など）を管理するサイト「サービスプロバイダ」が提供するAPIの接続許可証「トークン」を、サービスプロバイダを通じて、リソースを利用したサービスを提供する別のサイト（例えば、写真を現像するサイト）「コンシューマ」へ発行し、IDとパスワードの代わりにトークンを渡してサービスプロバイダ上のリソースへアクセスさせる、ということになる。

 This specification was obsoleted by OAuth Core 1.0 Revision A on June 24th, 2009 to address a session fixation attack. The OAuth Core 1.0 Revision A specification is being obsoleted by the proposed IETF draft draft-hammer-oauth. The draft is currently pending IESG approval before publication as an RFC. Implementers should use RFC 6749: The OAuth 2.0 Authorization Framework instead of this specif

当ブログでこれまで何度かOpenSocialに絡んだOAuthについて取り上げてきましたが、MySpaceを参考にしていたため、署名方式としてHMAC-SHA1のみを対象にしてきました。しかしShindigを掘り下げる上でRSA-SHA1を避けて通ることはできず、むしろこちらについても十分な知識を得ていないとなかなか先に進めないことが分かりましたので、この機会にまとめてみます。(OpenSocialをある程度前提にしていますが、署名の話はOpenSocialに限らないものです。) 署名とは何か ITの世界で署名とは、問い合わせ元がその人であることを証明するための手段、と言えます。OAuthだと、コンシューマがサービスプロバイダに対して、名乗っている通りの者であることを証明することを意味します。これは、「自分」もしくは「相手と自分」にしか分からないものをリクエストに付け加えて送ることで実現さ