質問: OAuth1.0のRequest Tokenの必要性が分かりません. OAuth1.0ではHttpの使用を考慮するために, Clientは長い工程の後,Request Tokenと署名を渡し, Access Tokenを取得しています. ServerがAccess Tokenと署名を渡し,それを使用してAPIアクセスすることでも Httpの使用を考慮できるのではないでしょうか. Request Tokenありの場合とRequest Tokenなしの詳細な図を示しました. よく考えれると署名の処理が重たいという理由な気がしてきました. !Request Tokenありの場合 !Request Tokenなしの場合
回答: OAuth1.0(a)が考え出された当時は、適用されるシステムが「Client Credentialを安全に隠せるWeb Serverがあって、そのWeb Serverが最終的に保護リソース(=API)を利用する」というユースケースのみがサポート対象でした。つまり、APIを叩くために必要となる【AccessTokenはWeb Serverのみが入手して利用する】、ということですね。まずこれが大前提です。 OAuthの発想が「User Credential(パスワードとか)はユーザ認証を行うDomainでしか扱わせない」なので、一旦アプリのDomainからユーザ認証のDomainに移動しなければなりません。ユーザ認証が完了した後にアプリに戻す際に、AccessTokenを発行してそれを付けてアプリ側にリダイレクトで戻してしまうと、先ほどの大前提が崩れてしまいます。Web ServerではないUserAgentがAccessTokenを得ることができてしまうわけですね。それではダメなので、「確かに○○というユーザが認証されて、保護リソースへのアクセスを認可しましたよ、これをAccessTokenと交換してください」という意味を持つRequestTokenを代わりに発行してUserAgentに渡しているわけです。 Web Serverは、ハッキングされない限り、Client Credential(=Client Secretという共通鍵とか)を第3者に知られることなく安全に扱えるので、RequestTokenからAccessTokenに「私は正しいClientです」「はい、そうですね」と双方で確認できた上でAccessTokenを渡すことができる、というストーリーですね。 実は、既に時代はOAuth2に移行しています。OAuth2では、ご指摘の「RquestTokenを介さずにUserAgentにAccessTokenをすぐに渡す」というImplicit Grantという方式も規定されています。主に「APIをWebブラウザのJavaScriptから叩きたい」というニーズに応えるための方式です。 httpとhttpsと署名の関係は、何をどのように隠したいか、によって決まります。OAuth1の時は、Client Credentialを通信路にhttpで流すわけにはいかない、でもhttpsではなくhttpでもやりたい、っていう想定だったので、Client Credentialを通信路に流す代わりに署名が使われました。OAuth2では、httpsであればそもそもClient Credentialを通信路に流しても問題ないのでは?という感じで、署名計算は必要ないけれどhttps必須、という仕様に変わりました。