如果你開車去酒店赴宴，你經常會苦於找不到停車位而耽誤很多時間。是否有好辦法可以避免這個問題呢？有的，聽說有一些豪車的車主就不擔心這個問題。豪車一般配備兩種鑰匙：主鑰匙和泊車鑰匙。當你到酒店後，只需要將泊車鑰匙交給服務生，停車的事情就由服務生去處理。與主鑰匙相比，這種泊車鑰匙的使用功能是受限制的：它只能啟動發動機並讓車行駛一段有限的距離，可以鎖車，但無法開啟後備箱，無法使用車內其他裝置。這裡就體現了一種簡單的“開放授權”思想：通過一把泊車鑰匙，車主便能將汽車的部分使用功能（如啟動發動機、行駛一段有限的距離）授權給服務生。

2. OAuth 2.0 協議

之所以標註為 2.0，是因為最初有一個1.0協議，但這個1.0協議被弄得太複雜，易用性差，所以沒有得到普及。2.0是一個新的設計，協議簡單清晰，但它並不相容1.0，可以說與1.0沒什麼關係。所以，我就只介紹2.0。

在弄清楚OAUTH流程之前，我們先了解下OAUTH的一些術語的定義：

• OAUTH相關的三個URL：
  • Request Token URL: 獲取未授權的Request Token服務地址；
  • User Authorization URL: 獲取使用者授權的Request Token服務地址；
  • Access Token URL: 用授權的Request Token換取Access Token的服務地址；

　　第一步，應用向服務提供方申請請求令牌(Request Token)，服務提供方驗證通過後將令牌返回。這個步驟由於涉及到應用帳號密碼，在應用的服務端發起，所以這個步驟對使用者透明。

　　第二步，應用使用請求令牌讓瀏覽器重定向到服務提供方進行登入驗證和授權。服務提供方校驗請求令牌，將第三方的資料顯示給使用者，提示使用者選擇同意或拒絕此次授權。如果使用者同意授權，發放已授權令牌並將使用者引導到當前應用的註冊地址。這個步驟從重定向開始到引導回註冊地址之前，應用方並不參與使用者身份校驗和授權過程，確保第三方不可獲得使用者的真實帳號密碼。

　　第三步，用已授權令牌向服務提供方換取ATOK。第三方應用需在服務端發起請求，用帳號密碼和上一步的令牌換取ATOK，這個步驟對使用者而言也是透明的。如果前兩步分別是讓服務提供方認證應用和使用者，那這步就是使用者和服務提供方再次認證第三方應用。因為使用者瀏覽器將第二步的結果重定向到第三步，除非使用者DNS被劫持，否則就能確保重定向到的是合法的地址。曾經我很困惑在使用者授權之後為何不直接返回ATOK而需要再次換取，估計是出於對ATOK的安全考慮，使用者瀏覽器一端存在太多的可能性讓ATOK洩漏，最安全的辦法還是讓第三方服務端來獲取和保管ATOK。