華為帳號服務學習筆記（五）：OpenID Connect協議詳解

筆者在《華為帳號服務學習筆記（二）：OAuth2.0 協議詳解》《華為帳號服務學習筆記（三）：10 分鐘完成Authorization Code 模式客戶端Demo 開發》《華為帳號服務學習筆記（四）：Authorization Code 模式服務端Demo 開發》三篇文章中已經給大家詳細介紹了Auth2.0 協議，以及華為帳號服務基於該協議開發的Authorization Code 授權模式客戶端、服務端開發指導，這種模式是華為官方推薦的模式，有伺服器的最好使用這種模式。華為還支援另外一種模式叫ID-Token 模式，這種模式既可以用於有伺服器場景也可以用於無伺服器場景，有人會問既然這種模式兩種場景都能用，為啥不推薦這種模式呢？這就要從這種模式使用的協議說起了，下面就來解答這個問題。

 

什麼是OpenID Connect 協議

OpenID Connect 協議是基於OAuth2.0 實現的 使用者認證規範，對OAuth2.0 介面進行了擴充套件，透過在協議中擴充套件身份認證所需的ID Token 欄位，向第三方應用提供身份認證服務。 OpenID Connect 是“認證”和“授權”的結合。

         也就是說OpenID Connect 協議就是在Auth2.0 協議的基礎上增加了一個ID Token 欄位，用於身份認證。Auth2.0 協議規定使用者授權後能獲取到一個Code ，而OpenID Connect 協議獲取到的就是個ID Token 了。那什麼是ID Token 呢？

         ID Token 也是一個JWT ，或者又稱 JSON Web Token ，JWT 是一個編碼令牌，它由三部分組成：頭部，有效負載和簽名。在獲得了 ID 令牌後，客戶端可以將其解碼，並且得到被編碼在有效負載中的使用者資訊，如：

         {

   “iss ”: “ ”,

   “sub ”: “10965150351106250715113082368 ”,

   “email ”: “hexianbin@example.com ”,

   “iat ”: 1516239022,

   “exp ”: 1516242922

}

其中：

•        iss ：是令牌釋出者

•        sub ：是使用者的唯一識別符號

•        email ：是使用者的郵箱

•        iat ：用 Unix 時間表示的令牌釋出時間

•        exp ：Unix 時間表示的令牌到期時間

當然，還可以透過Scope 指定ID-Token 中是否包括個人主頁（profile ）、郵箱（email ）、地址（address ）和電話（phone ）等。

OpenID Connect 認證流程

因OAuth2.0 四種授權模式中密碼式和憑證式直接信任第三方，不需要在進行附加認證， OpenId Connect 協議主要提供了授權碼模式和隱含模式。

 

授權碼模式： 必須有後臺伺服器

在有應用伺服器的情況下，客戶端將ID Token 傳送給應用服務端，應用伺服器對ID Token 進行校驗，並從ID Token 中解析出使用者的帳號資訊。

 

 

隱含模式： 即 OpenID Connect 預設模式，適用於純前端應用

這種模式因為沒有服務端，直接在客戶端進行ID Token 的校驗和解析。

 

如何校驗和解析ID Token ？

1 、使用通用JWT 庫（如jwt.io ）對 ID-Token 進行解碼；

2 、對ID-Token 進行簽名校驗（驗證資料完整性）

3 、驗證iss 欄位是否是對應的令牌釋出者

如華為帳號服務的iss 為： ，那我們就需要驗證iss 欄位是不是等於 。

4 、驗證aud 欄位的值是否等於app id

5 、驗證ID Token 是否過期

6 、驗證完成後，再解析出使用者資訊，使用者資訊包括：使用者暱稱、頭像、郵箱等。

 

瞭解了以上內容之後，我們就來回答一開始中的這個問題，為什麼code 模式比ID Token 模式更好呢？筆者覺得主要原因是ID Token 模式即使在有伺服器的場景下，當ID Token 過期後，需要使用者重新走一遍授權流程；而Code 模式是可以在伺服器端進行AT 保活的，保證AT 不會過期，這樣就不用再需要使用者去走一遍授權流程了，所以體驗上會更優。。

 

** 後續筆者會不斷輸出相關領域的優質內容，希望大家持續關注本帳號!**