A. 基於OAuth2的OIDC (OpenId Connect) 身份認證
OIDC（OpenID Connect）是在OAuth2上構建了一個身份層，是一個基於OAuth2協議的身份認證標准協議。
OAuth2是一個授權協議，它無法提供完善的身份認證功能【1】，OIDC使用OAuth2的授權伺服器來為第三方客戶端提供用戶的身份認證，並把對應的身份認證信息傳遞給客戶端。
如果用OAuth2進行認證，會有許多問題。
OAuth2提供了 Access Token 來解決授權第三方 客戶端 訪問受保護資源的問題；OIDC在這個基礎上提供了 ID Token 來解決第三方客戶端標識用戶身份認證的問題。OIDC的核心在於在OAuth2的授權流程中，一並提供用戶的身份認證信息（ ID Token ）給到第三方 客戶端 ， ID Token 使用 JWT 格式來包裝。此外還提供了 UserInfo的 介面，用戶獲取用戶的更完整的信息。
主要的術語以及概念介紹:
OIDC的流程由以下5個步驟構成：
OIDC對OAuth2最主要的擴展就是提供了 ID Token 。 ID Token 是一個安全 令牌 ，是一個 授權伺服器 提供的包含用戶信息（由一組Cliams構成以及其他輔助的Cliams）的 JWT 格式的數據結構。
另外 ID Token 必須使用JWS進行簽名和JWE加密，從而提供認證的完整性、不可否認性以及可選的保密性。一個 ID Token 的例子如下：
因為OIDC基於OAuth2，所以OIDC的認證流程主要是由OAuth2的幾種授權流程延伸而來的，有以下3種：
Resource Owner Password Credentials Grant是需要用途提供賬號密碼給RP的，賬號密碼給到RP了，就不再需要ID Token了。
Client Credentials Grant這種方式根本就不需要用戶參與，更談不上用戶身份認證了。這也能反映授權和認證的差異，以及只使用OAuth2來做身份認證的事情是遠遠不夠的，也是不合適的。
這里主要介紹基於Authorization Code的認證請求/答復。
所有的 Token 都是通過 Token EndPoint 來發放的。構建一個OIDC的Authentication Request需要提供如下的參數：
以上這5個參數是和OAuth2相同的。除此之外，還定義了一些參數【2】例如：
一個簡單的示例如下：
在 授權伺服器 接收到認證請求之後，需要對請求參數做嚴格的驗證。驗證通過後引導 EU 進行身份認證並且同意授權。在這一切都完成後，會重定向到 RP 指定的回調地址，並且把 code 和 state 參數傳遞過去。比如：
RP 使用上一步獲得的 code 來請求 Token EndPoint ，這一步同OAuth2。然後 Token EndPoint 會返回響應的 Token ，其中除了OAuth2規定的部分數據外，還會附加一個 id_token 的欄位。 id_token 欄位就是上面提到的 ID Token 。例如：
其中看起來一堆亂碼的部分就是 JWT 格式的 ID Token 。在 RP 拿到這些信息之後，需要對 id_token 以及 access_token 進行驗證。至此，可以說用戶身份認證就可以完成了，後續可以根據 UserInfo EndPoint 獲取更完整的信息。
除了Core核心規范內容多一點之外，另外7個都是很簡單且簡短的規范，另外Core是基於OAuth2的，也就是說其中很多東西在復用OAuth2。
OpenId Connect定義了一個發現協議，它允許Client輕松的獲取有關如何和特定的身份認證提供者進行交互的信息。在另一方面，還定義了一個Client注冊協議，允許Client引入新的身份提供程序（identity providers）。通過這兩種機制和一個通用的身份API，OpenId Connect可以運行在互聯網規模上運行良好，在那裡沒有任何一方事先知道對方的存在。
UserIndo EndPoint 是一個受OAuth2保護的資源。在 RP 得到 Access Token 後可以請求此資源，然後獲得一組 EU 相關的 Claims ，這些信息可以說是 ID Token 的擴展，
成功之後相應如下：
【1】 OAuth2中的access_token
【2】 [認證 & 授權] 4. OIDC（OpenId Connect）身份認證（核心部分）
B. wordpress主題被加密了，麻煩幫忙解一下，謝謝
解密後如下
?><?php get_sidebar(); ?>
</div><!-- end columns_wrapper -->
<div id="footer">
<div class="footer-left">
<p>Design <a href="http://www.slyar.com/">Slyar Home</a><br />
Support <a href="http://www.slyar.com/">Slyar Home</a> | <a href="http://www.slyar.com/">Slyar Blog</a> | <a href="http://www.slyar.com/">Slyar Home</a></p>
</div>
<div class="footer-right">
<p>?<?php echo date('Y');?> <a href="<?php bloginfo('siteurl');?>/" title="<?php bloginfo('name');?>" ><?php bloginfo('name');?></a></p>
</div>
</div> <!-- end footer -->
</div> <!-- end page -->
<?php wp_footer(); ?>
</div>
<script type="text/javascript">
var menu=new menu.dd("menu");
menu.init("menu","menuhover");
</script>
</body>
</html>
C. 一篇文章帶你分清楚JWT,JWS與JWE
隨著移動互聯網的興起，傳統基於session/cookie的web網站認證方式轉變為了基於OAuth2等開放授權協議的單點登錄模式（SSO），相應的基於伺服器session+瀏覽器cookie的Auth手段也發生了轉變，Json Web Token出現成為了當前的熱門的Token Auth機制。
JSON Web Token（JWT）是一個非常輕巧的規范。這個規范允許我們使用JWT在兩個組織之間傳遞安全可靠的信息。
現在網上大多數介紹JWT的文章實際介紹的都是JWS(JSON Web Signature),也往往導致了人們對於JWT的誤解，但是JWT並不等於JWS，JWS只是JWT的一種實現，除了JWS外，JWE(JSON Web Encryption)也是JWT的一種實現。
下面就來詳細介紹一下JWT與JWE的兩種實現方式：
JSON Web Signature是一個有著簡單的統一表達形式的字元串：
頭部用於描述關於該JWT的最基本的信息，例如其類型以及簽名所用的演算法等。
JSON內容要經Base64 編碼生成字元串成為Header。
payload的五個欄位都是由JWT的標准所定義的。
後面的信息可以按需補充。
JSON內容要經Base64 編碼生成字元串成為PayLoad。
這個部分header與payload通過header中聲明的加密方式，使用密鑰secret進行加密，生成簽名。
JWS的主要目的是保證了數據在傳輸過程中不被修改，驗證數據的完整性。但由於僅採用Base64對消息內容編碼，因此不保證數據的不可泄露性。所以不適合用於傳輸敏感數據。
相對於JWS，JWE則同時保證了安全性與數據完整性。
JWE由五部分組成：
具體生成步驟為：
可見，JWE的計算過程相對繁瑣，不夠輕量級，因此適合與數據傳輸而非token認證，但該協議也足夠安全可靠，用簡短字元串描述了傳輸內容，兼顧數據的安全性與完整性。
D. springboot 集成jwt
原文地址: https://mp.weixin.qq.com/s/Jo3PZoa7nL99c8UCxPiTTA
以前一直使用的是jjwt這個JWT庫，雖然小巧夠用, 但對JWT的一些細節封裝的不是很好。最近發現了一個更好用的JWT庫nimbus-jose-jwt，簡單易用，API非常易於理解，對稱加密和非對稱加密演算法都支持，推薦給大家！
簡介
nimbus-jose-jwt是最受歡迎的JWT開源庫，基於Apache 2.0開源協議，支持所有標準的簽名(JWS)和加密(JWE)演算法。
JWT概念關系
這里我們需要了解下JWT、JWS、JWE三者之間的關系，其實JWT(JSON Web Token)指的是一種規范，這種規范允許我們使用JWT在兩個組織之間傳遞安全可靠的信息。而JWS(JSON Web Signature)和JWE(JSON Web Encryption)是JWT規范的兩種不同實現，我們平時最常使用的實現就是JWS。
使用
接下來我們將介紹下nimbus-jose-jwt庫的使用，主要使用對稱加密（HMAC）和非對稱加密（RSA）兩種演算法來生成和解析JWT令牌。
對稱加密（HMAC）
對稱加密指的是使用相同的秘鑰來進行加密和解密，如果你的秘鑰不想暴露給解密方，考慮使用非對稱加密。
要使用nimbus-jose-jwt庫，首先在pom.xml添加相關依賴；
創建JwtTokenServiceImpl作為JWT處理的業務類，添加根據HMAC演算法生成和解析JWT令牌的方法，可以發現nimbus-jose-jwt庫操作JWT的API非常易於理解；
創建PayloadDto實體類，用於封裝JWT中存儲的信息；
在JwtTokenServiceImpl類中添加獲取默認的PayloadDto的方法，JWT過期時間設置為60s；
創建JwtTokenController類，添加根據HMAC演算法生成和解析JWT令牌的介面，由於HMAC演算法需要長度至少為32個位元組的秘鑰，所以我們使用MD5加密下；
/**
keytool -genkey -alias jwt -keyalg RSA -keystore jwt.jks
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-rsa</artifactId>
<version>1.0.7.RELEASE</version>
</dependency>
/**
/**
/**
/**