OIDC 介紹

OIDC是Open ID Connect的縮寫。
各種應(yīng)用都需要做用戶驗證。最簡單的方式是在本地維護一個數(shù)據(jù)庫，存放用戶賬戶和證書等數(shù)據(jù)。這種方式對于業(yè)務(wù)來說可能會不太友好：

注冊和賬戶創(chuàng)建過程本來就很無聊。對于很多電商網(wǎng)站來說，它們會允許非登陸用戶添加購物車，然后讓用戶下單時再注冊。乏味的注冊流程可能會導(dǎo)致很多用戶放棄購買。
對于那些提供多個應(yīng)用的企業(yè)來說，讓各個應(yīng)用維護各自的用戶數(shù)據(jù)庫，不管從管理還是安全層面來說，都是一個很大的負擔。
對于這個問題，更好的方案是將用戶認證和授權(quán)這些事情交給專門的identity provider（idp）服務(wù)來處理。

google、facebook、twitter這些大廠，就為它們的注冊用戶提供了這類idp服務(wù)。一個網(wǎng)站可以通過使用這類idp服務(wù)來極大簡化用戶的注冊和登錄流程。

Open ID Connect 特性

在了解Open ID Connect之前，可以先了解下Open ID: Open ID 介紹。 需要注意的是Open ID 和Open ID connect是不一樣的, Open id connect更加先進。

OpenID Connect是位于OAuth2.0協(xié)議之上的身份層。 它使客戶端能夠基于授權(quán)服務(wù)器的驗證來驗證最終用戶的身份。OAuth2.0提供了授權(quán)，即基于權(quán)限驗證是否有權(quán)訪問某些內(nèi)容的過程。 OpenID Connect提供身份驗證，即驗證身份的過程。 這可以通過表單身份驗證來完成，其中sql服務(wù)器存儲必要的信息以對用戶進行身份驗證。

OpenID Connect在2014年發(fā)行。雖然它不是第一個idp標準，但從可用性、簡單性方面來說，它可能是最好的。OpenID Connect從SAML和OpenID 1.0/2.0中做了大量借鑒。

oAuth2.0使用access token來授權(quán)三方應(yīng)用訪問受保護的信息。OpenID Connect遵循oAuth2.0協(xié)議流程，并在這個基礎(chǔ)上提供了id token來解決三方應(yīng)用的用戶身份認證問題。OpenID Connect將用戶身份認證信息以id token的方式給到三方應(yīng)用。id token基于JWT(json web token）進行封裝，具有自包含性、緊湊性和防篡改性等特點。三方應(yīng)用在驗證完id token的正確性后，可以進一步通過oAuth2授權(quán)流程獲得的access token讀取更多的用戶信息。

OpenID Connect大獲成功的秘訣：

• 容易處理的id token。OpenID Connect使用JWT來給應(yīng)用傳遞用戶的身份信息。JWT以其高安全性（防止token被偽造和篡改）、跨語言、支持過期、自包含等特性而著稱，非常適合作為token來使用。
• 基于oAuth2.0協(xié)議。id token是經(jīng)過oAuth2.0流程來獲取的，這個流程即支持web應(yīng)用，也支持原生app。
• 簡單。OpenID Connect足夠簡單。但同時也提供了大量的功能和安全選項以滿足企業(yè)級業(yè)務(wù)需求。

OpenID Connect所涉及的角色如下：

• 用戶。
• RP：Relying Party，申請授信信息的可信客戶端（既上文中提到的三方應(yīng)用）。
• OP：OpenID Provider，提供身份認證的服務(wù)方，比如google和facebook等公司的系統(tǒng)。
• id token：包含身份認證信息的JWT。
• user info api，返回用戶信息的接口，當RP使用id token來訪問時，返回授權(quán)用戶的信息。

Open ID 認證流程

原文鏈接： Introduction to OpenId Connect

身份提供者(OpenID Provider)向最終用戶提供一個ID token，該token 被編碼為JWT（Json Web token），看起來像這樣：

image.png

聲明(Claims)
Token 包含位于payload中的聲明，這些只是id token上的屬性，其中包含有關(guān)實體的值：

• Subject=身份提供商提供的唯一ID
• Issuing Authority=發(fā)行令牌的身份提供商OP（https://idp.com）
• Audience =可以使用此令牌的依賴方RP
• Issue Date=發(fā)行令牌的日期和時間
• Expiration Date=令牌到期的日期和時間

Token 還可以包含其他請求的聲明，例如電子郵件或地址。 ID Token 使用json網(wǎng)絡(luò)簽名進行數(shù)字簽名，以實現(xiàn)完整性和不可否認性。 header，payload 和signature被組合到一個JWT中。

Scopes
ID Token 包含用于檢索信息的聲明(claims)，但也可以使用scopes。 這些是包含聲明的特定信息集。 OpenID Connect中預(yù)定義了四個標準范圍，一個是openid，這是強制性的，另外四個是可選的。

• openid（這指定openid是必需的，是強制性的?。?/li>
• profile（基本個人資料信息，可選）
• email （可選）
• address（可選）
• phone（可選）

認證流程

如何獲取ID token

這個過程涉及到idp，也就是google、facebook等公司，通過驗證用戶的session或者證書并做認證。而用戶的session或者證書的可信載體則是瀏覽器。

瀏覽器彈出框?qū)τ趙eb應(yīng)用來說是將用戶重定向到idp的一種比較好的方式。Android或者IOS app需要喚起本系統(tǒng)的瀏覽器來做這件事。嵌入式的web view不是一個可信的方式，因為沒法阻止這個web view所在的app來竊取用戶的密碼等信息。用戶認證應(yīng)該永遠使用獨立于app的可信方式，比如系統(tǒng)的瀏覽器。

注意，OpenID Connect并不會特別說明用戶該如何被認證，這個邏輯有idp自己決定。
id tokens通過oAuth2.0協(xié)議獲得。
獲取id token的流程分為如下幾類：

• authorization code flow。這是最常用的流程，主要用在web應(yīng)用以及原生app場景。id token主要依靠后端而不是前端比如javascript和OP進行交互來獲取。
• implicit flow。對于基于瀏覽器（javascript）的應(yīng)用，它們往往沒有后端，id token是直接從OP的重定向里面得到的（依靠前段代碼）。
• hybrid flow。上面兩種方式的綜合，前后端獨立獲取id token，這種方式很少使用。

認證代碼流(Authorization code flow)
成功驗證客戶端后，authentication code flow 將返回authentication code。 這可以通過表單身份驗證（用戶名和密碼）完成。 后端收到authentication code 后，后端可以使用authentication code直接從身份提供者訪問access_token或id_token。 ID或訪問令牌永遠不會公開給客戶端。 對于常規(guī)Web應(yīng)用程序/原生移動應(yīng)用程序/臺式機原生應(yīng)用程序，此流程非常理想。

image.png

隱式流(Implicit code flow)
客戶端經(jīng)過身份驗證后，隱式流向瀏覽器公開ID和訪問令牌。 你可能已經(jīng)知道，這是最不安全的身份驗證方法。 XSS和網(wǎng)絡(luò)釣魚是將訪問令牌暴露給入侵者的主要危險之一。 在https上運行網(wǎng)站可以緩解其中的一些危險。 隱式流主要用于在瀏覽器中運行的應(yīng)用程序（Javascript應(yīng)用程序）。

image.png

混合流(hybrid flow)
混合流是代碼流和隱式流的組合。 身份驗證后返回id token，該令牌用于訪問各種資源。 如果您需要在前端和后端使用單獨的令牌，這將特別有用。一個token用來訪問資源（API）， 另外一個token用來獲取刷新令牌(refresh token)。

詳細信息可以查看官網(wǎng)：Open Id connect介紹
其他文章：OIDC 介紹