oauth 是乙個開放授權協議，允許第三方應用訪問服務提供方中註冊的終端使用者的某些資源，且不會把帳號和密碼提供給第三方。
oauth 允許通過服務提供商授予的乙個臨時令牌而不是使用者名稱密碼來獲取使用者的資源，這些資源可以是受限的，令牌的時間段也可以是受限的。
1.終端使用者
存放在服務提供方的受保護的資源的擁有者
2.第三方應用
通常是**，如提供**列印服務的**
3.服務提供者
1. request token
用於獲取訪問令牌
2. user authorization
重定向的 uri ，讓使用者授權
3. access token request
獲取訪問令牌
雅虎的圖畫的比較好，就用它了
圖表 1 oauth 流程圖
2. 第二步：獲取oauth_token，客戶端應用將請求引數編碼後用指定的oauth_signature_method及shared_secret&簽名，yahoo獲得請求引數用同樣的方法對引數簽名，然後和請求引數裡的oauth_signature對比，如果相同則客戶端認證通過，授予臨時的oauth_token和oauth_secret；
3. 第三步：客戶端應用重定向使用者瀏覽器到yahoo的登入頁面，請求引數帶oauth_token，yahoo驗證該token是否是自己頒發，如果是則可能讓使用者登入（可能使用者已經登入），並明確告知使用者客戶端應用要獲取使用者什麼個人資料，使用者同意後，yahoo重定向使用者瀏覽器到客戶端應用的oauth_callback頁面，並帶引數oauth_verifier；
5. 第五步：客戶端應用用之前的oauth_access_token獲取新的token;
注意：這裡的oauth_timestamp和oauth_nonce是為防止重放攻擊而設定的。具體的來講：請求者不能在一段時間（伺服器允許的客戶端和服務端的時間差）內傳送同樣的請求兩次或以上，如果在這個時間段之後再次發生這個請求，則會因為超出服務端允許的時間差而被拒絕。
1. consumer key
第三方應用在服務提供方註冊的標示（類似使用者名稱）
2. shared secret
服務提供方提供的驗證第三方應用的金鑰（類似密碼）
3. reqeust token
請求令牌，用於標示這次請求
4. access token
訪問令牌，表示第三方應用已獲得使用者授權
協議中涉及的三方
圖表 2 協議中的三方
為描述方便，服務提供方簡稱 sp 。
1. sp 和客戶端之間的交換金鑰的通訊是通過 ssl 加密隧道（ https ）的，因此排除第三方攻擊者竊取金鑰資料的可能。
2. 獲取 access token 之後，通過 http 獲取使用者資源，需要客戶端的金鑰和 access secret 簽名資料，第三方攻擊者很難猜測這兩個金鑰，除非客戶端洩露。
3. 由於 sp 對客戶端是不夠信任的，因此我們要防止客戶端用各種方式繞過使用者授權竊取使用者資料。如通過已授權的使用者 a 去獲取使用者 b 的資訊，即通過獲得授權使用者 a 的 access token 和 access secret 猜測分析使用者 b的 access token 和 access secret 。
2009 年 4 月 23 日， oauth 宣告了乙個 1.0 協議的安全漏洞。該漏洞影響了 oauth 1.0 核心規範第 6 節的 oauth的認證流程（也稱作 3 階段 oauth ）， oauth core 協議 1.0a 版本解決了這一問題。
攻擊者到乙個合法的 consumer 站點獲得乙個 request token
利用 trap site 讓受害者授權這個 request token
之後針對 callback 的不同，有幾種不同的處理方法：
a) 如果 provider 站點對第二步（請求使用者授權 , 圖中第 3 步）中的 callback 沒有限制，那麼攻擊者可以利用trap site 將 callback 設為自己的站點，然後通過這個 callback 判斷受害者何時完成授權。等到受害者授權後，攻擊者訪問合法的 callback 來獲得受害者的 access token
b) 其他的情況下（使用預定義的靜態 callback 、沒有 callback 由使用者手工完成授權），那麼攻擊者和受害者之間進行競爭，當攻擊者恰好在受害者授權和訪問 callback 的間隙訪問合法的 callback ，那麼攻擊者就獲得了受害者的 access token
1.0a 的版本提供了以下改進：
1. oauth_callback 在第一步即獲取 request token 時（ get request token ，圖中第二步）就必須提供，如果不需要重定向，則其值必須為 oob （ out_of_band configuration ），服務提供方此時返回引數oauth_callback_confirmed ，且值為 true 。在第二步即驗證階段（圖中第三步）不接受該引數。
2. 驗證完成後會返回驗證碼（ oauth_verifier ）為的是在沒有 callback 的時候，服務提供方顯示給使用者，然後使用者可以在第三方應用的裝置上輸入，標示自己已經授權（和未授權的使用者分開），然後第三方應用必須加上該驗證碼去獲取 access token
然而實際上 oauth1.0 最終版（已經成為 rfc5849 標準）已經沒有這個安全的漏洞了。
oauth 協議（ rfc5849 標準）文件上提出了以下安全考量，對應
1. 似乎說 rsa_sha1 更安全
2. 建議用 ssl 或者 tls 保證請求的安全
3. 建議用 ssl 或者 tls 保證確認服務提供者的身份
4. 客戶端 proxy 或者 cache 的安全
5. 服務端金鑰的安全儲存
6. 客戶端金鑰的安全儲存
7. 警告使用者，防止使用者的疏忽
8. 由於第三方應用的不可信任（可能希望獲取更多的使用者資源），需對授權的資源嚴格的分類，並告知明確使用者可能存在的風險
9. 金鑰的安全性，最好是真正的隨機數
10. dos/ddos 攻擊
11. sha-1 自身的漏洞
12. 簽名只是保證了 base_string 的完整
13. csrf （ cross site request forgery ）
14. clickjacking
15. 客戶端金鑰的安全
上面的各條中黑體的條款，我們需要注意，其他是客戶端或者使用者需要防範的，我們服務提供方需要給使用者足夠的資訊去確認授權的風險。
其實協議 1.0 定稿後，已經廣泛使用，其本身不會有什麼安全漏洞，但協議的實現可能存在漏洞，這是我們需要花精力去測試的。
uboot簡介及分析
1 uboot的作用 在系統剛上電的時候，系統需要執行一段程式去初始化硬體，設定軟體執行環境，最後呼叫系統核心，這段程式就是uboot 在了解uboot過程之前我們要搞清楚，整個系統可以執行起來，從軟體上來看到底是有哪幾部分組成？1 bootloader 引導程式，即上電之後就執行的第乙個程式 2 ...
samba後台程序及安全模式簡介
識別 samba 後台程式 linux 伺服器通常作為守護程式 daemon 來實現，這一詞源於希臘神話，其中守護神 daemon 是超自然生物。linux 守護程式在後台執行以便執行一些有用的任務。samba 伺服器套件由幾個守護程式組成，包括 smbd nmbd 和 winbindd。swat ...
samba後台程序及安全模式簡介
識別 samba 後台程式 linux 伺服器通常作為守護程式 daemon 來實現，這一詞源於希臘神話，其中守護神 daemon 是超自然生物。linux 守護程式在後台執行以便執行一些有用的任務。samba 伺服器套件由幾個守護程式組成，包括 smbd nmbd 和 winbindd。swat ...