前言
jwt、oauth2、oidc等，都是和認證授權相關的規範或者解決方案，因此要理解他們，就需要從業務場景的適用性一步步的分析和認識。
一、認證授權業務場景理解
就個人目前的理解來看，一個好的軟件系統的構成可能需要包含但不限於以下幾個方面：
功能
性能
拓展
安全
不論是從公司或者項目角度而言，還是從個人開發者的角度而言，有相當大一部分可能都只在功能部分停留。
何謂功能，我的理解就是實現業務需求裏的要求，滿足需求文檔需要的效果，流程走通、可交付使用。因此這裏說的功能，和僅僅是流程走通還是有一定區別的。
在功能的基礎上，有的客戶可能在需求裏就對一些性能有要求，或者有些公司的項目團隊有一定追求，那麼可能就更進一步，會在功能的基礎上再注重性能。
那麼這裏的性能就會涉及到整個架構的設計、技術的選型以及代碼的規範和調優。
至於拓展性，實際上和上邊一條就有些類似了，不論是動機還是處理方式都差不多。
只不過在分佈式、微服務和容器盛行的今天，很多項目的第一選擇就是這兩個，那麼在架構層面來說，其實一開始就具備了一定的拓展性。
而說到安全，很多人第一時間想到的可能是用戶名密碼這些，這也是最常見到的安全裏的內容。
但是實際上軟件的安全遠遠不止用戶名密碼的管理和校驗，還包含數據傳輸的安全、資源權限的安全等。
而標題所說的認證授權，也正是安全範疇裏的內容，更確切的說，應該是資源權限控制的範疇。
二、token的理解
token這個詞，很多做開發的應該都知道，比較常見的就是在用戶名密碼登陸後，後臺生成一個token，然後客戶端保存token。
客戶端只有獲取了正確的token後，在發起業務請求時攜帶這個token，才能正常進行後續的業務處理。
那麼這個token既然是爲了保證安全、用來校驗用戶是否登錄的，token本身的安全自然也是需要注意的，所以一般的token就有了簽名加密的處理。
而至於token裏的內容定義以及格式定義，理論上講只需要客戶端和服務端協商一致即可。
但是考慮到token的通用性和廣泛性，因此慢慢的就有了一些token定義的規範，一個目前比較通用的token規範就是jwt。
三、jwt的理解
jwt是json web token的簡稱，標準的jwt格式token包含了三段，分別是token頭、token主題和token簽名，三部分以點符號分割。
jwt作爲一種規範，也可以說一種解決方案，本身就可以拿出來做很多的解讀，更多jwt的知識可以參考阮一峯的博客：
http://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html
對於認證授權來說，只需要先了解到這個jwt是一種通用規範和格式的數據，安全、通用就好。
jwt是一種token規範，那麼在用戶登錄的時候，就可以生成這種規範的token，這樣在後續解碼、簽名驗籤、數據處理等需求上就可以減少很多的溝通成本。
但是jwt只是處理token規範的問題，卻不處理其他token規範之外業務的問題，比如token如何能方便刷新的問題，比如究竟是簡單地登錄業務，還是涉及到第三方服務的授權業務，還是帶有授權和認證的業務等等。
而這個問題，就引申出了oauth2。
四、認證和授權的理解
要想弄清oauth2，實際上必須先弄清認證和授權這兩個概念。
從英語單詞來看，認證和授權其實非常的像，分別是 authentication 和 authorization，在實際開發中，很多人也不太能分清楚。
即使是我自己，雖然近段時間有一定的理解，卻不敢保證就是對的，只能說現階段我覺得是這樣。
我理解的認證，從字面意思說，就是身份的認證；而授權，則是資源的授權。
借用網絡上別人寫的：認證解決的是你是誰，而授權解決的是可以給你什麼。
那麼從這個角度來說，一個常規的登錄獲取token，之後在其他業務中校驗token，其實只能算是認證的一個範疇，因爲這個token的作用只是校驗訪問者的身份以及是否檢驗過這個身份，只要身份驗證通過，所有資源都可以用。
假如在服務端的接口中涉及到了不同的權限問題，然後能夠從token中獲取到這些權限，並根據這些權限確定是否要處理該請求的資源，那麼這裏纔算是真的涉及到了授權。
需要注意的是，這裏的權限是資源的權限，而不是用戶的角色權限這些，這是兩個概念。
更多認證授權的理解，也可以參考其他的博客，例如：
https://www.cnblogs.com/jinhengyu/p/10257792.html
五、oauth2的理解
和jwt一樣，oauth2也是一種規範，因爲規範，就逐漸的形成了一些特定的解決方案，例如spring的oauth2。在認證和授權的業務中，oauth2解決的就是授權規範的問題。
在業務交互的過程中，oauth2授權直觀的提現，也是通過token。
標準的oauth2的token同樣是遵循jwt標準，不同的是，在普通jwt的token基礎上加入了更多的內容。
oauth2標準的token有兩個：access_token和refresh_token。
access_token用來訪問資源時授權，包含基礎授權信息，refresh_token的作用是在access_token失效後直接續簽access_token，即上邊說的如何方便刷新和續簽token的問題。
同時，oauth2中的授權分爲客戶端模式、授權模式、簡化模式、密碼模式四種，可以根據不同的業務場景。
和上邊用戶名密碼登陸不同的是，oauth2中解決的更多是涉及到第三方服務的業務。
對於oauth2的詳細理解和四種授權模式，可以參考後邊鏈接中的內容，不過有些地方可能需要參考更多其他博客，不見得都對。
http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html
六、oidc
大多數系統，實際上用到oauth2就已經足夠了，因爲即使說服務涉及到了第三方，但是大多數時候這些第三方資源可能都是公司內，或者一個大的團隊內。
但是隨着互聯網的發展，越來越多的系統或應用會集成外部的第三方，例如支付寶等第三方支付、例如QQ等第三方登錄。
因此，openid這個技術和規範就應運而生，這個技術解決的就是外部第三方交互時的一個身份認證問題。
結合上邊所說，認證和授權分別屬於不同的範疇，解決的也都是不同的問題，因此在這種涉及到第三方，如果再涉及到資源權限的系統中，就會引入一個新的規範，即oidc。
OIDC=(Identity, Authentication) + oauth2，我的理解就是openid+oauth2。
具體的用法和實現上就是，OIDC在oauth2的基礎上又加了一個token，叫做id_token。
id_token同樣的遵循jwt規範，只不過裏邊的內容是能夠體現用戶身份的信息。
因此，OIDC裏就會有三個token：access_token、refresh_token和id_token。
對於實際使用來說，理解到這裏應該就差不多能夠明白爲什麼的有的應用會一次返回三個token，不知道究竟該使用那個了。
若想了解OIDC更多的內容，可以參考下邊的博客：
https://www.cnblogs.com/linianhui/p/openid-connect-extension.html