我在面試Web相關崗位時，經常會問面試者一個問題，什麼是認證，什麼是授權？（也請你花一分鐘時間思考一下）
…
部分面試者會給我如下的答案：
當使用者開啟瀏覽器或者App的時候，如果某些功能不是匿名使用者能操作的，那麼我們就會將使用者引導到登入頁面，讓使用者輸入自己的使用者名稱和密碼、當然也可能是手機簡訊驗證等方式，在安全性較高的系統還會要求輸入驗證碼。如果驗證通過，那麼使用者就擁有了可以操作這些功能的許可權。這裡的登入動作就是認證，對不同型別使用者進行的存取許可權切分就是授權。
能給到類似如上答案的面試者，已經是思路相對清晰的候選人，而更多的面試者是含糊的告訴我，在使用者登入的這個步驟裡，就已經同時完成認證和授權的動作。
這些答案不能說不對，但隨著你對系統整體認知程度的加深，對這些基礎概念的理解應該要有更成體系的認識。否則如果認證和授權真如上述所說只是個使用者登入的過程，那為何還需要引入OAuth 2.0這種相對複雜的規範，甚至是更上層的OpenID Connect（OpenID Connect會在後續有專題講解，當前可以簡單理解為基於OAuth的上層規範）？
所以，我嘗試以目前的理解來解釋何為認證，何為授權，以引入後續對OAuth 2.0相關的介紹。能力有限，不當之處煩請指出。
我們設想這樣的場景，比如小A需要通過網上銀行，查詢自己的賬戶餘額，那小A大概會按如下步驟進行：
這是一個典型的登入操作，我們抽取其中的參與方，可以抽象出三個要素：
但這並不全面，這中間還有一個關鍵的隱式要素，叫：
我們通過這四個要素將場景重新描述一遍：認證實體，通過賬號密碼的認證方式，在信任系統中進行登入操作，在認證成功後，信任系統返回一個憑證(即token)，認證實體通過持有該憑證，可以在信任系統中進行後續的操作。
OK，至此，我們對我們所熟悉的典型的登入場景進行了拆解，抽象出認證實體、認證方式、信任系統和憑證四個要素，可是，為什麼要把簡單的事情複雜化？接下來，我們來看下這個場景的變種。
還是查詢賬戶餘額的場景，銀行內部的某個管理系統A，它自身並沒有賬戶餘額相關的資料，但是它希望網上銀行系統為它提供一個介面，可以通過傳遞賬戶id，去查詢指定賬戶餘額（請注意，真實的世界不會對提出這樣的需求，即便有類似需求，也不會在網銀系統實現）。那基於上述小A的案例和當下的需求，我們立刻可以給出如下設計：
如上的場景在於我們的認證實體發生了改變，由人變成了伺服器（由小A變成了管理系統A），所以我們可以得到的啟發是，所謂的認證，其認證實體最常見是人，但並不僅限於人，還可以是：
由認證實體不同，我們可能採用的認證方式也不盡相同，比如在上述案例中，分別出現過使用者級賬號密碼、系統級賬號密碼、交易密碼和磁卡。接下來，我們對管理系統A和網上銀行間的認證進行升級：
很明顯，我們棄用了系統級使用者密碼的方式，而改用非對稱中的簽名演演算法，其原因：
熟悉密碼學的同學應該明白此次升級的意義（不熟悉也沒關係，後續會有專題介紹）。
此時我們再引申想一想，在網上銀行中，當我們需要進行轉賬類交易時，即便我們剛登入過網上銀行系統，它仍然會再一次要求進行手機簡訊驗證碼的認證，來保障這類敏感的交易的可靠性，我們管這類認證叫二次認證。更有甚者，當我們的交易金額足夠大時，網上銀行在要求進行手機簡訊碼認證的同時，還需要插上ukey來共同完成此次認證，而這類認證則叫做多要素認證。
在我看來，認證的方式很多，我們無法說明哪種方式是最好的，但基於認證實體、業務場景、行業規範和使用者體驗，我們可以採用相對合理的認證方案。但讀至此處，希望大家能意識到認證方式的多樣性，絕非「使用者名稱密碼」就能涵擴的。
我們注意到在上述案例中有個重要的參與者，就是網上銀行，也就是我們抽象要素中的信任系統。那現在請你花一分鐘想想，為什麼它叫信任系統？
…
你是不是有過這樣的體驗，一封不明來路的郵件，帶來一條不明去向的連結，點選連結後要你輸入自己的個人資訊，比如身份證、手機號等。我想，但凡有一點安全常識的人，也不會輸入這些資料，甚至直接忽視這封郵件。而這條連結所引導你去的系統，就是你不信任的系統。在這種場景下，所謂的信任系統，是你可以放心的將自己的隱私資料交由其保管的系統，比如金融類（網銀、手機銀行等）、出行類（滴滴、攜程等）或電商類（淘寶、京東等），這些系統一般都有大廠的背書，你信任它們，放心將自己的隱私資料交由它們保管。
而這時候，出現一個第三方系統，比如不知名天氣系統A，它希望能通過分析你在攜程的出行和酒店記錄，來提醒你天氣變化注意加衣服，多麼貼心和友善的系統，但你能放心的把自己在攜程的賬號密碼託管給天氣系統A嗎？答案自然是否定的，因為這類中小系統未必有足夠的安全級別去保障你的資料安全，如果你託管的攜程賬號因此洩露，則相關的隱私資料將在惡意攻擊者的眼前一覽無餘。
可是，我們因此就要否認這類需求的意義嗎？在講求開放和數位化的今天，顯然不行。因此，我們的「認證（其實此處更準確的是授權）」有了更大的挑戰，當非信任系統出現時，我們如何提供受限的方式，讓它合法的獲取信任系統的資料，這其實也是OAuth 2.0要解決的主要問題之一。
此處我們先不解釋如何解決此類問題，你暫時只需要知道，當非信任系統出現並想要獲得你的隱私資料時，整個認證和授權的方式將變得複雜和有趣起來。
在上述的討論中我們已經大概明晰，認證的作用，是通過某種認證方式，讓信任系統能驗證待認證實體的身份，並在驗證通過後頒發憑證的過程。而認證和授權經常混為一談的原因，是因為授權往往緊隨其後，是當系統在驗證完待認證實體身份後，授予該實體存取某些特定資源的許可權。
我們回顧之前講解認證時涉及的場景：
通過上面的回顧，我們會發現授權有幾個重點：
只有在授權的有限週期內，通過憑證存取被授予的資源，才能存取成功，否則都應被拒絕。
所以，如上是對認證和授權的概述，由此我們可以知道，當認證實體、認證方式和信任系統等出現變更時，我們的技術實現也將對應變更。而在一些更復雜的情況，比如單點登入、開放系統間的資料存取等場景下，我們要如何保證應用和使用者的資料安全，這是一個非常大的挑戰。好在OAuth 2.0的出現，為我們提供了一個正規化，我們可以以此為規範，去實踐這些複雜場景下的應用。OAuth 2.0也是本系列部落格後續的重點。
有興趣一起交流和學習的，可以加我微信：lihaoxuexi