理解OIDC協議和認證機制

當互聯網應用越來越多，每個應用程序都實現了自己的身份存儲、認證和授權，用戶需要在應用上反覆的註冊與登錄，體驗糟糕，用戶身份信息無法在多個應用間共享與同步。當使用企業應用時，企業提供了一系列應用，儘管是同一用戶操作，但還是不得不切換註冊與登錄。

是否可以有那麼一種方式，我在某個代理網站註冊一個賬號，如果登錄其他網站時，其他網站可以到代理網站去獲取信息。只要代理網站足夠富有生命力，那麼總是可以省略很多乏味的註冊登錄流程。

這些想法在技術的發展過程中出現了，如WS-Federation、SAML2.0、OpenID、OAuth、OIDC…

OpenID&OAuth發展歷史

圖片

還有一些修訂和擴展，此處就不體現了，主要是想聚焦於OpenID和OAuth是不一樣的。

  • OpenID是面向身份認證，對用戶身份進行認證判斷是否有效。
  • OAuth是面向授權過程，在已知當前用戶身份合法後，控制用戶能夠訪問的資源，考慮保護被訪問的資源。

OpenID

OpenID是一個去中心化的網上身份認證系統。對於支持OpenID的網站，用戶不需要記住像用戶名和密碼這樣的傳統認證標記。取而代之的是，他們只需要預先在一個作為OpenID身份提供者（identity provider, IdP）的網站上註冊。OpenID是去中心化的，任何網站都可以使用OpenID來作為用戶登錄的一種方式，任何網站也都可以作為OpenID身份提供者。OpenID既解決了註冊問題而又不需要依賴於中心性的網站來確認數字身份。

OpenID給用戶提供一個統一網絡身份，遵守OpenID網絡身份，遵守OpenID協議的應用網站（在OpenId術語里叫Relying Parties，即RP）需要用戶登錄時，引導用戶到第三方OpenID身份提供方（OpenId術語里叫OpenID identity provider，即OP）去認證，認證通過即登錄成功。這樣就省去了每個應用網站註冊、登錄的煩惱與乏味。解決了最開始提到的一個問題，各應用需要獨立完成註冊與登錄流程，需要實現與維護獨立的用戶數據庫。

OAuth

OAuth是一個授權協議，解決的是應用可以訪問用戶在另一應用上的某些授權資源，但此應用不需要知道用戶在另一應用上的賬戶密碼，即無需向另一應用透露用戶的憑據便可以訪問另一應用上受控的資源。

  • 2006年11月，當時布萊恩·庫克正在開發Twitter的OpenID實現。與此同時，社交書籤網站Ma.gnolia需要一個解決方案允許使用OpenID的成員授權Dashboard訪問他們的服務。這樣庫克、克里斯·梅西納和來自Ma.gnolia的拉里·哈爾夫（Larry Halff）與戴維·雷科爾頓會面討論在Twitter和Ma.gnolia API上使用OpenID進行委託授權。但他們討論得出結論，認為OpenID沒有完成API訪問委託的開放標準。
  • 2007年4月，成立了OAuth討論組，這個由實現者組成的小組撰寫了一個開放協議的提議草案。來自Google的德維特·克林頓獲悉OAuth項目後，表示他有興趣支持這個工作。
  • 2007年7月，團隊起草了最初的規範。隨後，Eran Hammer-Lahav加入團隊並協調了許多OAuth的稿件，創建了更為正式的規範。
  • 2007年10月，OAuth Core 1.0最後的草案發佈了。
  • 2008年11月，在明尼阿波利斯舉行的互聯網工程任務組第73次會議上，舉行了OAuth的BoF討論將該協議納入IETF做進一步的規範化工作。這個會議參加的人很多，關於正式地授權在IETF設立一個OAuth工作組這一議題得到了廣泛的支持。
  • 2010年4月，OAuth 1.0協議發表為RFC 5849，一個非正式RFC。
  • 2012年10月，OAuth 2.0發佈，正式發表為RFC 6749。OAuth 2.0是OAuth協議的下一版本，但不向下兼容OAuth 1.0。OAuth 2.0關注客戶端開發者的簡易性，同時為Web應用、桌面應用、手機和智能設備提供專門的認證流程。

Open ID Connect

OpenID團隊本來希望用戶使用OpenID來進行身份認證， 但因為授權過程包括認證過程作為一部分，所以授權意味着經過了認證這一過程。由此，一些用戶選擇了OAuth身份認證的簡易性，並且由於「管理用戶憑據的任務可以委託給外部服務」以及「因為新用戶註冊過程可以省略，使用該服務的障礙變得更低」等優點而迅速佔據主導地位，使用OAuth2.0作為身份認證的趨勢變得流行。

OpenID團隊不得不承認用戶更喜歡OAuth2.0，因此，他們在OAuth之上定義了一個新的身份認證規範OpenID Connect(OIDC)，這個規範基於OAuth2.0進行了小幅擴展，在OAuth2.0上構建了身份層，使其可用作身份認證協議。

圖片

即OpenID Connect (OIDC) 是基於 OAuth 2.0 構建的身份認證協議。

OpenID+OAuth 2.0=OpenID Connect

OIDC主要術語

  • Claim: 聲明信息，簡要格式展示(如身份證上格式)。
  • Claims Provider: 聲明信息提供方(如OAuth2.0中的Authorization Server能夠返回Id token，其中攜帶着聲明信息)。
  • End-User(EU): 人類參與者(完成認證活動的人)。
  • ID Token: 包含EU身份信息的聲明(Claim)，以JWT(Json Web Token)格式進行存儲傳遞。JWT具有自包含性、緊湊性和防篡改機制等特點。使得ID Token可以安全的傳遞給第三方應用並且容易被驗證。
  • OpenID Provider (OP): 提供身份認證的服務方，OAuth2.0中的Authorization Server(授權服務器)，用來提供身份認證服務以及返回Claim信息給第三方應用(Relying Party)。
  • Relying Party (RP)：受信任的第三方應用(OAuth2.0中的Client)，需要EU完成鑒權，並從OP處獲得Claim信息的應用。
  • UserInfo Endpoint：用戶信息的接口，當RP使用Access token請求該接口時，能夠返回當前用戶的身份信息。
    圖片

OIDC協議簇

OIDC由一系列規範文檔組成，包括一個核心文檔和多個可選支持的文檔來提供擴展支持：

  • Core：必選。定義了OIDC核心的功能，在OAuth 2.0之上構建身份認證，以及使用聲明(如身份證上的簡要描述)方式來傳遞用戶的信息。
  • Discovery：可選。定義了第三方應用如何動態發現OIDC服務提供方元數據文檔(比如提供的服務地址，採用的加密方法，支持的授權類型等等）。
  • Dynamic Registration：可選。定義了第三方應用如何註冊到OIDC身份提供方。
  • OAuth 2.0 Multiple Response Types：定義了幾種新的為OAuth2.0響應方式(原來常見的授權碼code、隱式授權token基礎上增加了id_token以及混合code、token和id_token的方式)。
  • OAuth 2.0 Form Post Response Mode：可選。在OAuth2.0的響應參數上擴展了OIDC所需的參數。提供了基於form表單響應信息的模式，使用post請求類型傳給第三方應用，響應參數以application/x-www-form-urlencoded格式存儲body中。
  • RP-Initiated Logout: 可選。定義了第三方應用如何註銷當前登錄用戶的機制。
  • Session Management：可選。定義了如何管理OIDC上已登錄用戶的會話數據，以便當OP上的用戶註銷時，也能夠方便在RP上註銷。
  • Front-Channel Logout：可選。基於前端的註銷機制，使得第三方應用不需要嵌入認證服務方的iframe來註銷。
  • Back-Channel Logout：可選。基於後端的註銷機制，定義了RP和OP直接如何通信來完成註銷。
  • OpenID Connect Federation: 可選。定義了如何在OP和RP間建立可靠的信任的機制。
  • Initiating User Registration via OpenID Connect: 可選。提供一種方式允許在RP指示下，能夠在OP上註冊用戶的機制。
    如下圖所示，上部分描述OIDC的協議簇，以及其中最為核心的Core規範。下部分是作為支撐OIDC的其他協議規範。

圖片

對於這些協議來講，可能看着就難受，簡要了解個概念即可，實際開發時這些都會逐漸浮出水面。

OIDC&OpenID2.0差異

  • OpenID Connect執行許多與OpenID 2.0相同的任務，但是API更友好且可使用在原生應用和移動應用。
  • OpenID Connect 定義了用於可靠簽名和加密的可選機制。
  • OAuth 1.0a和OpenID 2.0的集成需要擴展，而OIDC本身集成了OAuth2.0。

OIDC&OAuth2.0差異

OIDC仍然使用OAuth中的授權服務器將用戶身份認證信息以Id token的方式給到第三方應用，第三方應用可以驗證用戶標識並從中獲取用戶的基本信息以及通過OAuth2.0的授權流程訪問用戶的詳細信息。如下圖所示，對於用戶認證部分採用認證協議如WS-Fed、OIDC等，對於資源的訪問控制以OAuth2.0協議為主。

圖片

OIDC中的Id token和OAuth2.0中核心的Access token各自效力或是關注的部分不同。

  • OAuth2提供了Access Token來解決授權第三方應用訪問受保護資源的問題；
  • OIDC遵循OAuth2.0協議流程在這個基礎上提供了ID Token來解決第三方應用標識用戶身份的問題。
    圖片

OIDC抽象流程

OIDC的流程主要由以下5個步驟構成：

  1. 第三方應用(RP)發送認證請求到認證服務方(OP)
  2. 用戶在認證頁面進行認證與選擇授權內容
  3. 認證服務方(OP)對認證請求進行驗證，發送Id token及Access token給第三方應用(RP)
  4. 第三方應用可使用Access token請求用戶信息或其他授權內的資源
  5. 資源服務對Access token校驗並返回用戶信息或資源
    圖片

流程上，在OAuth2.0中授權碼模式和隱式授權模式下，OIDC和OAuth2.0是一樣的，但有幾個授權模式在某些情況下，在OIDC中就不存在了，當用戶無需經過身份認證過程即可獲得Access token，比如如下兩種模式。

  • 資源所有者密碼憑證授權(Resource Owner Password Credentials Grant)：第三方應用能夠獲取到用戶的登錄憑證就直接可以向授權服務器請求Access token，如此，就去掉了標識用戶身份這一過程了。
  • 客戶端憑證授權(Client Credentials Grant)：這種是標識客戶端，直接的參與者人都沒有加入到流程中，也不存在標識用戶是誰了。

OIDC的幾種認證方式

OIDC的認證流程主要是由OAuth2的幾種授權流程延伸而來的，主要有以下3種：

  • 授權碼流程(Authorization Code Flow)：基於OAuth2的授權碼流程，在原來code換取Access token的基礎上增加了一個Id token。
  • 隱式流程(Implicit Flow)：基於OAuth2的隱式流程，在原來從授權服務器重定向到第三方應用僅返回Access token的基礎上增加了一個Id token。
  • 混合流程(Hybrid Flow)：混合了授權碼流程(Authorization Code Flow)和隱式流程(Implici Flow)，能夠按照參數配置的不同，控制Id token的返回位置與Access token的有無。
    注意：如上省略了Refresh token，關注於Id token和Access token。

授權碼流程

1、第三方應用通過瀏覽器重定向到授權服務器(OP)的認證頁面來進行用戶認證與執行授權流程。重定向時使用的參數是基於OAuth2.0中的大部分參數。主要如下幾個

  • scope：必選。選擇的授權範圍，當是OIDC請求時，需要包含openid選項，如下示例所示。
  • response_type：必選。響應類型方式，使用授權碼流程時，為code.
  • client_id：必選。第三方應用提前在授權服務器處註冊得到的id值。
  • redirect_uri：必選。重定向到OP認證授權完畢後重定向到RP的地址。
  • state：推薦。第三方應用(RP)提供的一個字符串，授權服務器(OP)會原樣返回給第三方應用(RP)，以阻止CSRF攻擊。
    如上幾個是常使用到的授權碼流程中所需的參數，實際上還有許多其他參數可以依照不同場景的需要使用上。其他參數信息//openid.net/specs/openid-connect-core-1_0.html#AuthRequest

圖片

2、當用戶完成認證信息填寫與執行授權操作後，授權服務器(OP)對用戶認證信息的審核和授權範圍的校驗。有效後重定向到第三方應用(RP)指定的回調地址(第1步中的redirect_uri)，將code和state參數作為查詢參數附加在回調地址後。

圖片
3、第三方應用(RP)通過code來請求認證服務方的Token EndPoint換取Token。

圖片

然後Token EndPoint會返迴響應的Token，其中除了OAuth2規定的部分數據外，還會附加一個id_token的字段。

{
    "access_token": "SlAV32hkKG",
    "token_type": "Bearer",
    "refresh_token": "8xLOxBtZp8",
    "expires_in": 3600,
    "id_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"
}

4、請求用戶信息或授權內的資源。
圖片

隱式流程

在OAuth2.0中，隱式授權使用的response_type是token，而在OIDC中，變為了id_token token或是僅id_token，當僅使用id_token時，則不會返回Access token了。其餘參數則和OAuth2.0中的隱式授權一致。但OIDC中相比OAuth2.0隱式流程額外增加了一個參數nonce

  • nonce：必填。字符串值，用於將第三方應用的會話與 Id token關聯，並緩解重放攻擊。該值未經修改地從身份驗證請求傳遞到 Id token中。為了防止攻擊者猜中值，隨機數值中必須存在足夠的熵。

注意：隱式流程中OAuth2.0的state和OIDC的nonce區別

//stackoverflow.com/questions/46844285/difference-between-oauth-2-0-state-and-openid-nonce-parameter-why-state-cou

1、第三方應用(RP)攜帶參數跳轉到授權服務器(OP)的認證授權頁面，等待用戶認證與執行授權。

圖片

2、當授權服務器(OP)完成對用戶認證信息的審核和授權範圍的校驗，重定向回第三方應用(RP)並按照請求時的response_type返回id token、access token(當僅設置id_token時不返回)。注意url的hash部分(#後面)。

圖片

3、後續便是請求用戶信息或是授權內的資源。

混合流程

這種是將授權碼和隱式流程結合起來，一部分token來源於授權服務器(OP)重定向到第三方應用(RP)時帶過來，一部分來源於第三方應用(RP)向授權服務器(OP)發起請求而得到。這種流程中，response_type，可以混合著用，如code id_token，code token或是code id_token token。

1、第三方應用(RP)向授權服務器(OP)發起認證請求。此處使用授權碼和隱式中僅id_token的組合。

圖片

2、當授權服務器(OP)完成對用戶認證信息的審核和授權範圍的校驗,重定向回第三方應用(RP)並按照請求時的response_type返回id token、access token(當僅設置id_token時不返回)。

  • access_token：當response_type中有token選項時，則會返回access_token
  • id_token：當response_type中有id_token選項時，則會返回id_token
  • code：混合流程中，這個是必選的，所以總是會返回code。
    圖片

3、第三方應用(RP)通過code來請求授權服務器(OP)換取Token。這和授權碼流程一致了。

Id token格式

認證服務返回的ID Token需要嚴格遵守JWT(JSON Web Token)的定義，下面是JWT(JSON Web Token)的定義細節：

  • iss=Issuer Identifier: 必須。認證服務的唯一標識，一個區分大小寫的https URL，不包含query和fragment組件。
  • sub=Subject Identifier：必須。iss提供的終端用戶的標識，在iss範圍內唯一，最長為255個ASCII個字符，區分大小寫。
  • aud=Audience(s)：必須。標識ID Token的受眾，必須包含OAuth2的client_id，分大小寫的字符串數組。
  • exp=Expiration time：必須。超過此時間的ID Token會作廢。
  • iat=Issued At Time：必須。JWT的構建的時間。
  • auth_time=AuthenticationTime：終端用戶完成認證的時間。
  • nonce：發送認證請求的時候提供的隨機字符串，用來減緩重放攻擊，也可以用來關聯客戶端Session。如果nonce存在，第三方應用必須驗證nonce。
  • acr=Authentication Context Class Reference：可選。表示一個認證上下文引用值，可以用來標識認證上下文類。
  • amr=Authentication Methods References：可選。表示一組認證方法。
  • azpAuthorized party：可選。結合aud使用。只有在被認證的一方和受眾（aud）不一致時才使用此值，一般情況下很少使用。
    如下是一個典型ID Token的示例：
{
    "exp": 1614187991,
    "iss": "//authorization-server.com/oauth",
    "sub": "a0903223-a120-91e0-c342-10bd237c24c1",
    "aud": "client1",
    "iat": 1614151991,
    "auth_time": 0,
    "nonce": "n-0S6_WzA2Mj",
    "acr": "1",
    "azp": "client1",
    "nbf": 0,
    "typ": "ID",
    "session_state": "150df80e-92a1-4b0c-a5c5-8c858eb5a848",
    "userId": "123456",
    "preferred_username": "testera",
    "given_name": "tester",
    "family_name": "a",
    "email": "[email protected]"
}

關於ID Token的更詳細的定義請參見OpenID Connect Core 1.0。

參考

//openid.net/connect/

//www.jianshu.com/p/2c602974bc98

//baike.baidu.com/item/OpenID?wtp=tt

//www.imooc.com/article/4167

//www.cnblogs.com/linianhui/p/openid-connect-core.html

2022-03-31,望技術有成後能回來看見自己的腳步

Tags:

VirMach 便宜 VPS

QNews

QNews