繼今年四月份的 EasyOAuth Framework 1.0 上架到 Codeplex.com 後，除了再檢視程式本身以外，還吸取一些來自社群的意見 (雖然不多...)，以及配合 Windows Live ID 支援 OAuth 2.0 規格的發表，EasyOAuth Framework 也順勢改版到 2.0，同樣支援 Desktop Edition 與 Web Edition，可供桌面應用程式與 Web 應用程式的 OAuth 認證機制開發功能。
OAuth 的服務實作 ... 動念中。
自昨天首發 EasyOAuth Library for Desktop Application 後，今天再進一步發表 EasyOAuth Library for Web Application，這個函式庫可以支援 ASP.NET 與 ASP.NET MVC 應用程式開發支援 OAuth 功能的 Web 應用程式，它一樣可以在少量程式開發的情況下讓 Web 應用程式支援 OAuth 的功能，並且與 EasyOAuth Library for Desktop Application 一樣，可支援 Google, Facebook, Yahoo 與 Twitter 四種內建的 OAuth Service Provider。
這是筆者的第三個 Codeplex 開放原始碼專案，承繼前面四篇 OAuth Series 文章的說明，EasyOAuth Library 建構於 .NET Framework 之上，並且可以很容易的將 OAuth 的功能套用到自己的 .NET 應用程式中，並且開發人員可以依照 EasyOAuth Library 開放的介面，為非內建的 OAuth Service Provider 開發介面，以在 EasyOAuth Library 中直接使用。
在前一回完成了整個 OAuth 驗證與授權的流程後，程式應該可以成功取得 Access Token 以及 Access Token Secret，只要有這兩個資料，應用程式就可以以 Access Token 所代表的使用者來與 OAuth 服務的 Private API 來互動，大多數 OAuth 服務上的 API 都會需要先取得 Access Token 後才可以使用 (雖然還是有少數可以不用啦)，所以這篇文章就來說明怎麼使用 Access Token 來存取 Private APIs。
在前一篇文章中，已經大略的介紹過 OAuth 所使用到的各類參數，這些參數的產生與使用將會決定 OAuth 的程序是否順暢，因為在每次針對服務的 private API 呼叫，都會用到 OAuth 的認證標頭訊息，所以怎麼樣產生正確的訊息就是用戶端程式最重要的課題。
OAuth 使用上最難懂以及測試的，莫過於這些 OAuth 的參數，尤其是在 OWASP 的 Web Security Report 之下，又有 Improper Error Handling 的安全漏洞問題，因此在測試 OAuth 時，最容易吃的苦頭就是只知道 HTTP 400 (Bad Request) 或 HTTP 401 (Unauthorized)，有些服務還會提供一些錯誤訊息，但也有一點都不提供的，而且就算有提供，也不一定馬上就可以意識到問題在哪 (ex: Signature Invalid) … 往往都要做很多的實驗才能真正找到問題在哪，我在測試 Twitter 的 OAuth 時就吃了很多的苦頭… Orz。
OAuth，一個讓人又愛又恨的驗證協定，它讓許多主流的社群網站與網路服務打開了封閉已久的驗證大門，它也是在網路上公開個人或私人資訊 (private data) 前最主要的驗證管道之一，重要的是，在這個協定下，所有公開給外界的私密資料會受到兩個階段的保護，OAuth 保障使用者可以在應用程式要求資料前由使用者做明確授權，只有授權過的資源才會開放給應用程式存取用，而且 OAuth 公開的特性，可以讓應用程式在極少量程式碼的變更下，移植到不同的服務繼續使用，而 OAuth 協定也讓服務端精確的控制要開放的服務，並且提供使用者授權的管道以讓使用者能自由控制授權與否，而且用戶端應用程式只要利用 HTTP 協定即可使抈 OAuth 服務。