oauth 筆記
先看這篇搞清楚 1.0 跟 2.0 之間的差別。
Top Differences between OAuth 1.0 and OAuth 2.0 for API Calls
簡單來說就是，由於 1.0 設計跑在 HTTP 上，所以要自己發明一套安全檢查，
有各式各樣的驗證來確保使用者不會受到任何形式的攻擊。
超 複 雜 (OAuth 1.0)
然而 2.0 雖然在草稿中，但由於設計跑在 HTTPS 上，所以大部份的安全
檢查都不用做了，完全靠 HTTPS 即可。
超 簡 單 (OAuth 2.0 (draft-ietf-oauth-v2-15))
是說超簡單，但 spec 總是寫得落落長，看重點就好了。重點在
7.1. Access Token Types 裡的：
GET /resource/1 HTTP/1.1 Host: example.com Authorization: Bearer h480djs93hd8就這樣，不用一堆麻煩的 signature. 這種簡易的 Bearer access token,
要看 OAuth 2.0 Bearer Tokens. 總共有三種用法，分別是 HTTP header,
POST with form-encoded, 和 GET. (那不就是全部都行的意思？)
HTTP header 的話就像上面那樣，然後有個示範是這樣：
GET /resource HTTP/1.1 Host: server.example.com Authorization: OAuth2 vF9dft4qmT或許還在草稿中的關係，不知道到底要叫 Bearer 還是 OAuth2...
但總之用在 GET/POST 裡應該是叫 oauth_token. 也只要不要算
signature, 然後不要一堆各式各樣的 token (as in OAuth 1.0),
大抵上就算滿好處理的了。
唯一的麻煩只在最初的 authorization, 需要 redirect 那部份，
而這方面在 OAuth 2.0 看起來也簡單多了，就一個 code 而已。
大抵上確實跟 facebook Graph API 作法差不多，只有一些小細節不同。
* * *
我已經從 rest-graph 中拆出 rest-core, 接下來可能把他拆成一個
git submodule, 然後看情況要不要做成獨立的 gem. 接著大抵上
就能在上面再加蓋一層 OAuth 1.0/2.0 的 wrapper. 做 2.0 基本上
是沒什麼改變，重點是 1.0 真的好複雜，其實我不太想做。但現有的
oauth gem 我覺得滿難用的...
另一方面，透過 oa-oauth, 我注意到 faraday, 其地位大概就類似
目前用的 rest-client 吧。基本上我對 rest-client 是算相當滿意，
所以沒意外並不想換掉 rest-client. 但是 faraday 乍看之下，模組化
似乎做得比較徹底，或許能夠直接在上面做 OAuth 的東西，而不是
額外再去用一個 gem.
也就是說，也許 rest-graph 本身可以做成 faraday 的 middleware.
想到這裡，就有點猶豫不知道該不該動手。基本上雖然很多東西我都想
自己做，但那都是基於對現有的東西不滿。如果有一個我很滿意的東西
會動，我也就懶得重新造輪了。oauth gem 不行，oa-oauth 可以，
faraday 還沒細看，但有潛力。
怎麼辦呢...
關於這些考量，再下次某一篇中再重新描述。說真的，覺得有點沮喪。
* * *
OAuth 1.0 真的覺得很棘手。現在很可能需要他，但 oauth gem
我不喜歡，而且這雖然是個應該還會活很久的標準，可我對重做舊東西
興致實在不高。
而另一方面，看起來 linkedin 是想要另一個 client, 這是個機會。
真的不知道怎麼做好哩...
最後這是之前看 OAuth 1.0 的筆記。spec 落落長看起來真的很累，
簡單的範例比什麼都有用。
(server) init callback -> get oauth_token (tmp) / oauth_token_secret (tmp)
(client) redirect with oauth_token -> (from callback)
get oauth_verifier (tmp) + above oauth_token (tmp)
(server) authorize with oauth_verifier (tmp) and oauth_token (tmp) ->
get real oauth_token and real oauth_token_secret
(taken from my buzz notes)
