這個標準比較抽象，使用了很多術語，初學者不容易理解。其實說起來並不複雜，下面我就透過一個簡單的類比，幫助大家輕鬆理解，OAuth 2.0 到底是什麼。
一、快遞員問題
我住在一個大型的居民小區。
小區有門禁系統。
進入的時候需要輸入密碼。
我經常網購和外賣，每天都有快遞員來送貨。我必須找到一個辦法，讓快遞員透過門禁系統，進入小區。
如果我把自己的密碼，告訴快遞員，他就擁有了與我同樣的許可權，這樣好像不太合適。萬一我想取消他進入小區的權力，也很麻煩，我自己的密碼也得跟著改了，還得通知其他的快遞員。
有沒有一種辦法，讓快遞員能夠自由進入小區，又不必知道小區居民的密碼，而且他的唯一許可權就是送貨，其他需要密碼的場合，他都沒有許可權？
二、授權機制的設計
於是，我設計了一套授權機制。
第一步，門禁系統的密碼輸入器下面，增加一個按鈕，叫做"獲取授權"。快遞員需要首先按這個按鈕，去申請授權。
第二步，他按下按鈕以後，屋主（也就是我）的手機就會跳出對話方塊：有人正在要求授權。系統還會顯示該快遞員的姓名、工號和所屬的快遞公司。
我確認請求屬實，就點選按鈕，告訴門禁系統，我同意給予他進入小區的授權。
第三步，門禁系統得到我的確認以後，向快遞員顯示一個進入小區的令牌（access token）。令牌就是類似密碼的一串數字，只在短期內（比如七天）有效。
第四步，快遞員向門禁系統輸入令牌，進入小區。
有人可能會問，為什麼不是遠端為快遞員開門，而要為他單獨生成一個令牌？這是因為快遞員可能每天都會來送貨，第二天他還可以複用這個令牌。另外，有的小區有多重門禁，快遞員可以使用同一個令牌透過它們。
三、網際網路場景
我們把上面的例子搬到網際網路，就是 OAuth 的設計了。
首先，居民小區就是儲存使用者資料的網路服務。比如，微信儲存了我的好友資訊，獲取這些資訊，就必須經過微信的"門禁系統"。
其次，快遞員（或者說快遞公司）就是第三方應用，想要穿過門禁系統，進入小區。
最後，我就是使用者本人，同意授權第三方應用進入小區，獲取我的資料。
簡單說，OAuth 就是一種授權機制。資料的所有者告訴系統，同意授權第三方應用進入系統，獲取這些資料。系統從而產生一個短期的進入令牌（token），用來代替密碼，供第三方應用使用。
四、令牌與密碼
令牌（token）與密碼（password）的作用是一樣的，都可以進入系統，但是有三點差異。
（1）令牌是短期的，到期會自動失效，使用者自己無法修改。密碼一般長期有效，使用者不修改，就不會發生變化。
（2）令牌可以被資料所有者撤銷，會立即失效。以上例而言，屋主可以隨時取消快遞員的令牌。密碼一般不允許被他人撤銷。
（3）令牌有許可權範圍（scope），比如只能進小區的二號門。對於網路服務來說，只讀令牌就比讀寫令牌更安全。密碼一般是完整許可權。
上面這些設計，保證了令牌既可以讓第三方應用獲得許可權，同時又隨時可控，不會危及系統安全。這就是 OAuth 2.0 的優點。
注意，只要知道了令牌，就能進入系統。系統一般不會再次確認身份，所以令牌必須保密，洩漏令牌與洩漏密碼的後果是一樣的。 這也是為什麼令牌的有效期，一般都設定得很短的原因。
OAuth 2.0 對於如何頒發令牌的細節，規定得非常詳細。具體來說，一共分成四種授權型別（authorization grant），即四種頒發令牌的方式，適用於不同的網際網路場景。下一篇文章，我就來介紹這四種型別，並給出程式碼例項。
（完）