一、前言
oauth協議為使用者資源的授權提供了乙個安全的、開放而又簡易的標準。與以往的授權方式不同之處是oauth的授權不會使第三方觸及到使用者的帳號資訊（如使用者名稱與密碼），即第三方無需使用使用者的使用者名稱與密碼就可以申請獲得該使用者資源的授權，因此oauth是安全的。oauth是open authorization的簡寫。
說實話，每次見到官方定義的東西 都想
（╯' - ')╯︵ ┻━┻ （掀桌子） ┬─┬ ノ( ' - 'ノ)當然如果一切正常，qq會給你返回如下結果
response =3.5 拿著access_token去呼叫介面有access_token了還不為所欲為啊，獲取個暱稱，獲取的頭像，沒事發個說說，讀個微博啥的。到此oauth2.0 授權流程基本就結束了。當然這個access_token也是有時間的，一般為兩個小時。過期的話用返回的refresh_token重新整理，因為在請求介面的過程中傳輸的是access_token且只有兩小時的有效時間，即使是被別人截獲了，損失也不會太大，設計兩個小時的過期是為了安全考慮的。因為這一步的access_token是訪問介面的唯一憑據，並不會判斷呼叫者的**。所以是有可能被非法者截獲搞出一些事情的。
四、總結
1.關於code碼的問題：
q：為什麼不直接發放access_token而非要返回乙個code碼，然後用code換取access_token，這不是多次一舉嗎？
a：首先有這個想法很好，證明你是乙個有思想的同學。當初我也想了好半天。因為qq根據要跳回你的**才行，而跳轉到你的**是302重定向，只能是get請求，所以要傳遞給碼雲一些資料資訊的時候必須在url中新增引數，如果這時直接把access_token傳遞回來，就會暴露出來，這樣就很不安全，而且是依賴瀏覽器的，所以加了一部分，只把code碼傳回來，這樣即使code被暴露了也沒問題，因為碼雲要在再次用code碼和你的client_id,client_secret來請求qq，qq會做驗證，而這一步就可以不依賴瀏覽器了，你可以在伺服器用**模擬http請求獲取acess_token，這樣就比較安全了。
q：為什麼code要設計成一次性的？
a：倘若code能無限次用，那麼當使用者在上述情況下收回了許可權，但是由於code還能用，本身code又關聯了使用者的授權資訊，所以碼雲可能再次用code來換取token，這一步並沒有經過使用者的允許是違法的。所以不能讓code繼續使用。一次code表名了使用者的一次意願，並不是終生的意願。置於code為什麼要設定有效期，我想應該是你如果獲取了code不使用，qq也不會說一直幫你存著吧。
另外，當授權碼發放之後，qq肯定也肯定新增並記錄了使用者當前對哪個**發放了授權，這個記錄也為後來的使用者收回許可權做準備，如果使用者要收回許可權，直接對相關記錄操作就行。如下，是qq的授權管理：
2.關於oauth的標準協議
有關oauth的標準協議，各大廠商的內部實現可能不盡相同，有時候傳的引數多多少少會有一點出入，但是大體流程上都是這樣，而且有些必須引數都是一樣的。
協議的官方內容可以參考阮一峰老師的
理解oauth 2.0。另一篇 簡述 oauth 2.0 的運作流程 也很不錯。
深入淺出OAuth2 0授權
oauth協議為使用者資源的授權提供了乙個安全的 開放而又簡易的標準。與以往的授權方式不同之處是oauth的授權不會使第三方觸及到使用者的帳號資訊 如使用者名稱與密碼 即第三方無需使用使用者的使用者名稱與密碼就可以申請獲得該使用者資源的授權，因此oauth是安全的。oauth是open author...
一文讀懂OAuth2 0 入門
1.起源 oauth 2.0是授權用的工業化標準協議，是由ietf 國際網際網路工程任務組 oauth團隊開發，聚焦於簡化三方應用的授權流程 web應用 桌面應用 移動端應用 物聯網應用 主要作用是 為第三方應用頒發乙個令牌，授權其可在短期內訪問我方資料。2.原理 2.1 流程 2.1 第三方應用發...
重提「不要看《深入淺出mfc》！」一文
不要看 深入淺出mfc 一文中有了這樣的感慨 這本書對於mfc的講解對乙個初次接觸mfc的人來說，內容過於的晦澀難懂，大段大段的原碼引用，一定會使人頭暈目眩，不知所措，就算忍受著煎熬讀完，我敢保證，你坐在電腦前，開啟vc 肯定還是不知道怎麼用，甚至新增乙個控制項成員變數都不會，更不要說用mfc開發乙...