一，寫在前面的
這兩天在看論壇的L03API教程上面的oAuth，對於oAuth這個概念，一直還很模糊，找了很多國內的一些東西看的，當然還有論壇推薦的阮一峰的說明，但是總是感覺有種理不清楚的感覺。
加之國內很多教程對於非計算機專業的人理解不友好。
恰好在日本網站上看到了一些說明特別容易理解。就按照他們的思路自己寫了這一段圖。
順便說下，沒別的意思，對於IT一些術語的解釋，國內還是偏向於專業化了，甚至很多也只是翻譯國外的文章，沒有自己的理解，還有可能是我。。看的太少了吧。也有可能是我的實力不夠。
國外有很多感覺真的是寫給猴子看的，還有面向兒童的一些書，很適合我這種剛開始接觸某個概念的人來看。
- 廢話不多說了，上圖了。這是根據PPT做出來的簡圖。
- 如果想一次性看完的，可以去下面這裡直接看。
- 新手理解，不吝賜教。
- PPT幻燈片
為了不引起歧義補充說明一下，這篇只是很概括的說明了一下什麼是OAuth。
真正的授權肯定不是這麼簡單，到具體的OAuth授權模式上會更加複雜，看完這篇可以看看這篇我總結的授權模式，授權模式總結，比這個稍微沒這麼好懂一點，但我非計算機專業的我都能懂的話，應該認真看問題不大。本篇文章就不做贅述啦。
二，步驟圖
1.我們這裡有一份使用者的資料
2.使用者的資料我們儲存在資源伺服器(Resource server)裡
3.這時候有個 第三方應用程式（Third-party application）想要請求資源伺服器要使用者資料
4.為了讓使用者資料和第三方程式程式良好的互動，資源伺服器準備了一個API介面
5.第三方應用程式向資源伺服器請求使用者的資料
6.資源伺服器表示好的給你了
7.但如果這個第三方應用程式是惡意的第三方呢？那麼就會有以下的場景出現
8.所以我們需要一個機制來保護API介面，不能隨隨便便毫無安全可言的把使用者的資料送出去
9.這個最佳實踐就事先在第三方程式裡儲存一個令牌access_token
10.第三方應用程式在向資源伺服器請求使用者資料的時候會出示這個access_token
11.然後資源伺服器取出授權碼並且驗證是否有授權
12.授權通過，資源伺服器才會把使用者資料傳遞給第三方應用程式
13.但這種方案需要事先給第三方access_token
14.所以我們需要一個東西用來發行這個access_token，這時候認證伺服器 （Authorization server）登場了
15.認證伺服器負責生成並且發行access_token給第三方應用程式
16.接下來我們看一下目前的登場的人物有
- 第三方應用程式
- 資源伺服器
- 認證伺服器
- access_token
- 使用者資料
資源伺服器和認證伺服器有時候是同一臺伺服器
17.接下來我們來走一下流程 認證伺服器生成access_token
18.認證伺服器發行access_token授權給第三方應用程式
19.第三方應用程式拿著access_token去找資源伺服器要使用者資料
20.資源伺服器取出來access_token並驗證
21.驗證通過 使用者資料送出
22. 問題點來了
到上面為止有個很大的問題就是，認證伺服器生成access_token竟然沒人管！那豈不是隨便發行了，這不行，於是我們的使用者 （Resource Owner：資源所有者）出現了！
23. 解決
認證伺服器在發行access_token之前要先通過使用者的同意
24. 於是接下來就是
- 第三方應用程式向認證伺服器要access_token
- 認證伺服器生成之前先問問使用者能不能授權啊
- 使用者說好的可以給
- 認證伺服器生成access_token並且發行給第三方應用程式
25. oAuth2.0
第三方應有程式和這個認證伺服器之間圍繞著access_token進行請求和響應的等等就是oAuth2.0
