20770
OAuth1.0のRequest Tokenの必要性が分かりません．

OAuth1.0ではHttpの使用を考慮するために，  
Clientは長い工程の後，Request Tokenと署名を渡し，  
Access Tokenを取得しています．

ServerがAccess Tokenと署名を渡し，それを使用してAPIアクセスすることでも  
Httpの使用を考慮できるのではないでしょうか．

Request Tokenありの場合とRequest Tokenなしの詳細な図を示しました．  
よく考えれると署名の処理が重たいという理由な気がしてきました．

![Request Tokenありの場合](https://i.stack.imgur.com/CFLJm.jpg)

![Request Tokenなしの場合](https://i.stack.imgur.com/LxyC2.jpg)
CC BY-SA 3.0
2015-07-17T09:00:54.980
12444
2016-01-09T03:10:51.357
2015-07-19T01:39:19.413
10570
10570
question
oauth
OAuth1.0の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必須、という仕様に変わりました。
CC BY-SA 3.0
2016-01-09T03:10:51.357
20770
2016-01-09T03:10:51.357
531
12444
answer