說透OAuth 2.0 [1] - 什么是認證和授權？

引子

我在面試Web相關崗位時，經常會問面試者一個問題，什么是認證，什么是授權？（也請你花一分鐘時間思考一下）
…

部分面試者會給我如下的答案：

當用戶打開瀏覽器或者App的時候，如果某些功能不是匿名用戶能操作的，那么我們就會將用戶引導到登錄頁面，讓用戶輸入自己的用戶名和密碼、當然也可能是手機短信驗證等方式，在安全性較高的系統還會要求輸入驗證碼，如果驗證通過，那么用戶就擁有了可以操作這些功能的權限，這里的登錄動作就是認證，對不同型別用戶進行的訪問權限切分就是授權，

能給到類似如上答案的面試者，已經是思路相對清晰的候選人，而更多的面試者是含糊的告訴我，在用戶登錄的這個步驟里，就已經同時完成認證和授權的動作，

這些答案不能說不對，但隨著你對系統整體認知程度的加深，對這些基礎概念的理解應該要有更成體系的認識，否則如果認證和授權真如上述所說只是個用戶登錄的程序，那為何還需要引入OAuth 2.0這種相對復雜的規范，甚至是更上層的OpenID Connect（OpenID Connect會在后續有專題講解，當前可以簡單理解為基于OAuth的上層規范）？

所以，我嘗試以目前的理解來解釋何為認證，何為授權，以引入后續對OAuth 2.0相關的介紹，能力有限，不當之處煩請指出，

認證

我們設想這樣的場景，比如小A需要通過網上銀行，查詢自己的賬戶余額，那小A大概會按如下步驟進行：

• 小A打開瀏覽器，在地址欄輸入網上銀行的地址；
• 在網上銀行的登錄頁，輸入自己的賬號和密碼，并點擊登錄；
• 點開賬戶相關功能，查詢賬戶余額；

這是一個典型的登錄操作，我們抽取其中的參與方，可以抽象出三個要素：

• 認證物體：小A
• 認證方式：賬號密碼
• 信任系統：網上銀行

但這并不全面，這中間還有一個關鍵的隱式要素，叫：

• 憑證：登錄成功后頒發的token（比較典型的如JSESSIONID）

我們通過這四個要素將場景重新描述一遍：認證物體，通過賬號密碼的認證方式，在信任系統中進行登錄操作，在認證成功后，信任系統回傳一個憑證(即token)，認證物體通過持有該憑證，可以在信任系統中進行后續的操作，

OK，至此，我們對我們所熟悉的典型的登錄場景進行了拆解，抽象出認證物體、認證方式、信任系統和憑證四個要素，可是，為什么要把簡單的事情復雜化？接下來，我們來看下這個場景的變種，

認證物體變更

還是查詢賬戶余額的場景，銀行內部的某個管理系統A，它自身并沒有賬戶余額相關的資料，但是它希望網上銀行系統為它提供一個介面，可以通過傳遞賬戶id，去查詢指定賬戶余額（請注意，真實的世界不會對提出這樣的需求，即便有類似需求，也不會在網銀系統實作），那基于上述小A的案例和當下的需求，我們立刻可以給出如下設計：

1. 網上銀行生成一個特殊的賬號密碼，我們姑且稱之為系統級賬號密碼，并分配給管理系統A（因為系統級賬號并不同于小A的用戶級賬號，所以其存盤和驗證方式都不同）；
2. 網上銀行開放兩個新的端點：
   • /token端點， 根據系統級賬號密碼，可以換取憑證；
   • /account/{accountId}的端點，傳輸指定的賬戶id，即可回傳余額；
3. 管理系統A通過系統級賬號密碼在/token端點執行認證的動作，換回憑證；
4. 管理系統A攜帶憑證，并請求/account/{accountId}端點，以獲取指定accountId的賬戶余額；

如上的場景在于我們的認證物體發生了改變，由人變成了服務器（由小A變成了管理系統A），所以我們可以得到的啟發是，所謂的認證，其認證物體最常見是人，但并不僅限于人，還可以是：

• 如：上述場景中，通過系統級賬號密碼，認證訪問網上銀行介面的是合法的服務器；
• 如：在ATM取錢時，我們插入銀行卡，輸入對應的交易密碼，認證此次是合法的交易；
• 如：在小區門禁處刷卡時，認證此次是合法的出行；
• 其它；

認證方式變更

由認證物體不同，我們可能采用的認證方式也不盡相同，比如在上述案例中，分別出現過用戶級賬號密碼、系統級賬號密碼、交易密碼和磁卡，接下來，我們對管理系統A和網上銀行間的認證進行升級：

1. 管理系統A的系統管理員通過openssl生成一對公私鑰，將私鑰放置于管理系統A所在服務器，將公鑰放置于網上銀行所在服務器；
2. 網上銀行開放兩個新的端點：
   • /token端點，使用公鑰對傳入的簽名進行驗簽，如果驗簽通過，回傳憑證；
   • /account/{accountId}的端點，傳輸指定的賬戶id，即可回傳余額；
3. 管理系統A使用私鑰進行簽名，并傳入/token端點，驗證通過可換取憑證；
4. 管理系統A攜帶憑證，并請求/account/{accountId}端點，以獲取指定accountId的賬戶余額；

很明顯，我們棄用了系統級用戶密碼的方式，而改用非對稱中的簽名演算法，其原因：

• 用戶名密碼是較為不安全的方式：
  • 用戶名密碼會在網路中傳輸，存在泄露的風險；
  • 密碼如果要求不嚴格，存在弱密碼風險，容易被猜解；
  • 用戶名密碼存在撞庫風險；
• 公私鑰相對安全：
  • 公私鑰下發后將一直存盤在本地，泄露風險較小；
  • 公私鑰猜解的風險極低，在當前計算條件下，其數理邏輯上逆運算的耗時在十幾年甚至以上；
  • 公私鑰可輔助進行業務交易簽名，實作交易的不可抵賴性等；

熟悉密碼學的同學應該明白此次升級的意義（不熟悉也沒關系，后續會有專題介紹），

此時我們再引申想一想，在網上銀行中，當我們需要進行轉賬類交易時，即便我們剛登錄過網上銀行系統，它仍然會再一次要求進行手機短信驗證碼的認證，來保障這類敏感的交易的可靠性，我們管這類認證叫二次認證，更有甚者，當我們的交易金額足夠大時，網上銀行在要求進行手機短信碼認證的同時，還需要插上ukey來共同完成此次認證，而這類認證則叫做多要素認證，
在我看來，認證的方式很多，我們無法說明哪種方式是最好的，但基于認證物體、業務場景、行業規范和用戶體驗，我們可以采用相對合理的認證方案，但讀至此處，希望大家能意識到認證方式的多樣性，絕非“用戶名密碼”就能涵擴的，

信任系統變更

我們注意到在上述案例中有個重要的參與者，就是網上銀行，也就是我們抽象要素中的信任系統，那現在請你花一分鐘想想，為什么它叫信任系統？
…

你是不是有過這樣的體驗，一封不明來路的郵件，帶來一條不明去向的鏈接，點擊鏈接后要你輸入自己的個人資訊，比如身份證、手機號等，我想，但凡有一點安全常識的人，也不會輸入這些資料，甚至直接忽視這封郵件，而這條鏈接所引導你去的系統，就是你不信任的系統，在這種場景下，所謂的信任系統，是你可以放心的將自己的隱私資料交由其保管的系統，比如金融類（網銀、手機銀行等）、出行類（滴滴、攜程等）或電商類（淘寶、京東等），這些系統一般都有大廠的背書，你信任它們，放心將自己的隱私資料交由它們保管，

而這時候，出現一個第三方系統，比如不知名天氣系統A，它希望能通過分析你在攜程的出行和酒店記錄，來提醒你天氣變化注意加衣服，多么貼心和友善的系統，但你能放心的把自己在攜程的賬號密碼托管給天氣系統A嗎？答案自然是否定的，因為這類中小系統未必有足夠的安全級別去保障你的資料安全，如果你托管的攜程賬號因此泄露，則相關的隱私資料將在惡意攻擊者的眼前一覽無余，

可是，我們因此就要否認這類需求的意義嗎？在講求開放和數字化的今天，顯然不行，因此，我們的“認證（其實此處更準確的是授權）”有了更大的挑戰，當非信任系統出現時，我們如何提供受限的方式，讓它合法的獲取信任系統的資料，這其實也是OAuth 2.0要解決的主要問題之一，

此處我們先不解釋如何解決此類問題，你暫時只需要知道，當非信任系統出現并想要獲得你的隱私資料時，整個認證和授權的方式將變得復雜和有趣起來，

授權

在上述的討論中我們已經大概明晰，認證的作用，是通過某種認證方式，讓信任系統能驗證待認證物體的身份，并在驗證通過后頒發憑證的程序，而認證和授權經常混為一談的原因，是因為授權往往緊隨其后，是當系統在驗證完待認證物體身份后，授予該物體訪問某些特定資源的權限，

我們回顧之前講解認證時涉及的場景：

1. 小A在網上銀行登錄成功后：
   1. 網上銀行授予小A訪問網銀系統查詢類業務的權限，如賬戶查詢類、賬戶交易歷史查詢、基金理財產品查詢類等，只要攜帶憑證，小A可以隨意訪問此類業務；
   2. 對于動賬類交易，如發起一筆轉賬，小A需要通過手機短信驗證碼進行二次認證，才會被授予進行該筆轉賬交易的權限，如果需要發起另一筆轉賬，則還需要再進行一次完全獨立的二次認證；
   3. 當小A從網上銀行登出后，即便使用之前的憑證，也無法訪問任何業務；
2. 管理系統A通過系統級用戶密碼在網上銀行驗證成功后：
   1. 網上銀行授予管理系統A訪問/account和/token端點的權限；
   2. 當管理系統A訪問其它端點時，網上銀行將直接拒絕其請求；

通過上面的回顧，我們會發現授權有幾個重點：

• 授予的資源
• 授予的周期
• 授予的憑證

只有在授權的有限周期內，通過憑證訪問被授予的資源，才能訪問成功，否則都應被拒絕，

總結

所以，如上是對認證和授權的概述，由此我們可以知道，當認證物體、認證方式和信任系統等出現變更時，我們的技術實作也將對應變更，而在一些更復雜的情況，比如單點登錄、開放系統間的資料訪問等場景下，我們要如何保證應用和用戶的資料安全，這是一個非常大的挑戰，好在OAuth 2.0的出現，為我們提供了一個范式，我們可以以此為規范，去實踐這些復雜場景下的應用，OAuth 2.0也是本系列博客后續的重點，

有興趣一起交流和學習的，可以加我微信：lihaoxuexi