基于OAuth2.0, OpenID Connect和UMA的用戶認證授權系統架構

沈 桐，王 勇，劉俊艷

（北京匯通金財信息科技有限公司，北京 100053）

基于OAuth2.0, OpenID Connect和UMA的用戶認證授權系統架構

沈 桐，王 勇，劉俊艷

（北京匯通金財信息科技有限公司，北京 100053）

用戶認證系統的基本功能是用來證明一個用戶是他聲稱的那個用戶，并管理該用戶相關的基本信息。用戶授權系統的基本功能是授予用戶或應用權限訪問受保護的資源。OAuth2.0是一個用戶授權框架，該框架提供了使客戶端應用可以請求用戶授權該應用訪問該用戶受保護的資源的功能。OpenID Connect是基于OAuth2.0框架的用戶身份認證協議。UMA是基于OAuth2.0框架的用戶間授權協議。本文介紹了上述框架和協議的功能與實現，并整合三者嘗試搭建完整的用戶認證授權系統，使該系統架構具備功能上的完備性，良好的安全性，靈活的連通性，可擴展性，高性能以及高可用性。

用戶認證；用戶授權；OAuth2.0；OpenID Connect；UMA

0 用戶認證授權簡述

用戶認證系統的解決的核心問題是“確定用戶是他聲稱自己是的那個人”。用戶授權系統解決的核心問題是“用戶如何獲取權限來訪問受保護的資源”。用戶認證不一定發生在用戶授權之前，因為一個未認證的匿名用戶也可能能夠獲取一定的受限制的權限。對網絡應用來說，常見的用戶認證系統的實現方式是用戶使用用戶名和密碼在網絡應用提供的頁面進行登陸，網絡應用把用戶提供的信息與自身管理的用戶數據庫中的信息進行比對來進行認證。網絡應用的數量的爆炸性增長催生了對單點登陸系統的需求。而常見的授權系統則包括應用A直接拿著用戶的密碼等信息、模仿用戶訪問應用B下受保護的資源。這種授權方式的弊端很多，包括用戶密碼等敏感信息的泄露風險，以及應用B無法區分應用A與用戶自身究竟是誰在發起訪問等。

1 OAuth2.0簡述

OAuth2.0框架解決的基本問題是應用如何在不直接使用用戶的賬號密碼等敏感信息、不模仿用戶自身，就可以去獲取訪問受保護的資源的權限的問題[1]。OAuth2.0框架解決上述問題的思路是客戶端通過授權服務器獲取用戶簽發的訪問令牌，并拿著訪問令牌訪問資源服務器下受保護的資源，資源服務器在核實令牌有效后允許客戶端的訪問。授權服務器簽發的訪問令牌的主流形式是Bearer Token[2]，該令牌自身不包含任何客戶端和資源服務器可以解析的信息，也就是任何獲得了Bearer Token的客戶端均可通過該令牌訪問對應的資源，因此基于OAuth2.0的授權系統的所有http請求均需通過TLS加密傳輸。OAuth2.0框架是單純的用戶授權框架，本身不提供用戶認證功能，但可以基于OAuth2.0框架的授權體系去搭建用戶認證系統。

圖1 OAuth2.0組件視圖Fig.1 OAuth2.0 component view

如圖所示，OAuth2.0授權系統的基本組成部分為資源擁有者（用戶），客戶端應用，授權服務器和資源服務器四部分。一個典型的OAuth2.0授權流程是由客戶端應用發起，將用戶引導向授權服務器的授權接口，用戶在授權服務器上登陸并授權客戶端以訪問資源服務器中受保護資源的權限，客戶端從授權服務器獲得訪問令牌后持令牌訪問資源服務器，資源服務器驗證令牌有效[3]后返回正常的資源信息。OAuth2.0授權流程依據客戶端性質不同有授權碼流程，隱性流程，客戶端賬號密碼流程，用戶賬號密碼流程等，其中授權碼流程最為典型，該流程具體時序圖如圖2所示。

2 OpenID Connect簡述

OpenID Connect是基于 OAuth2.0框架的用戶認證協議[4]。OpenID Connect解決的基本問題是允許客戶端能夠使用用戶在授權服務器進行的身份認證作為自身系統的身份認證，以及允許客戶端通過簡單的 Restful風格的網絡調用獲取用戶的基本信息。基于OpenID Connect的用戶認證系統本質上是以 OAuth2.0授權服務器作為登陸點的單點登陸系統。基于OpenID Connect的用戶認證系統組件視圖如圖3所示。

如圖3所示，OpenID Connect用戶認證系統的基本組成部分為用戶，客戶端應用，身份提供者三部分。其中用戶與客戶端應用完全對應OAuth2.0中的同名組件，而OAuth2.0框架中的授權服務器和資源服務器共同組成此處的身份提供者。基于OpenID Connect的用戶認證系統的標準流程為用戶嘗試在客戶端應用登陸，客戶端應用將用戶引導至身份提供者頁面，用戶在身份提供者登陸后授權客戶端應用使用該用戶的身份登陸，身份提供者將OAuth2.0訪問令牌以及一個包含用戶基本登陸信息的 JWT令牌[5]——ID Token返回給客戶端，客戶端解析ID Token并驗證有效后認為用戶在客戶端登陸，并持令牌訪問身份提供者獲取用戶的詳細信息。具體流程時序圖如圖4所示。

3 UMA 簡述

UMA的全稱是User Managed Access，是基于OAuth2.0框架的用戶間授權協議[6]。UMA協議解決的基本問題是用戶與用戶間的授權，并允許用戶引入自定義的授權服務器。在OAuth2.0的基本組件之外，UMA協議引入了訪問申請者（Requesting Party）這一新組件。在 UMA協議中，資源擁有者負責協調授權服務器與資源服務器的關系，而訪問申請者則通過他所操作的客戶端去嘗試訪問受保護的資源，即由資源擁有者授權訪問申請者——很可能是不同的人——所掌控的客戶端應用訪問受保護的資源。通過允許用戶引入自定義的授權服務器，使得用戶可以完全掌控生態系統中哪些組件可以接觸到他自己的各種數據。基于 UMA協議的授權系統的基本組件如圖5所示。

圖2 OAuth2.0授權碼流程時序圖Fig.2 Sequence Diagram of the Authorization Code Flow of OAuth2.0 Framework

圖3 Op enID Connect組件視圖Fig.3 OpenID Connect component view

圖4 Op enID Connect用戶登陸時序圖Fig.4 User login sequence diagram of OpenID Connect

圖5 UMA 組件視圖Fig.5 UMA component view

如圖5所示，UMA在OAuth2.0的基礎上增加了訪問申請者這一組件，資源擁有者不再直接與客戶端應用發生聯系，授權服務器作為整個系統的核心，既需要提供API給資源服務器用于資源注冊、權限注冊以及令牌解析服務，還需要提供 API給客戶端用于訪問申請者的校驗和訪問令牌的簽發。在標準的UMA授權流程中，資源擁有者和訪問申請者各自負責一般的流程。對資源擁有者來說，首先由資源擁有者提供給資源服務器一個授權服務器的地址，資源服務器在發現了授權服務器的配置信息后、向授權服務器注冊自身，資源擁有者在授權服務器給資源服務器授權、允許其訪問授權服務器提供的Protection API（包括資源注冊、權限注冊以及令牌解析服務），資源服務器得到 Protection API Token后持該Token向授權服務器注冊資源集，最后資源擁有者在授權服務器上為注冊的資源設置訪問規則，此時資源擁有者在整個流程中需扮演的角色就基本結束了。對訪問申請者來說，首先訪問申請者引導客戶端應用訪問受保護的資源（此時客戶端應用并沒有足夠的授權），資源服務器解析客戶端的請求獲得要訪問的資源以及該資源對應的授權服務器后，向對應的授權服務器發起請求獲得授權票，并將該授權票以及授權服務器的地址返回給客戶端應用，客戶端應用獲取到授權服務器的地址后將自身注冊到授權服務器，客戶端應用再持授權票從授權服務器換取訪問令牌，授權服務器根據授權票獲得客戶端想要訪問的信息以及訪問策略，如果客戶端未提供訪問策略所需的足夠的聲明信息，則授權服務器會告知客戶端收集足夠的聲明信息后再申請訪問令牌，客戶端收集聲明信息的常見方式有將訪問申請者重定向到授權服務器的聲明收集地址并由訪問申請者在授權服務器登陸等，客戶端重新提交包含了額外的聲明信息的授權票后獲得訪問令牌，客戶端應用持令牌訪問資源服務器下的受保護的資源，資源服務器訪問授權服務器的令牌解析地址判斷令牌有效后，最后允許客戶端訪問受保護的資源。該流程的具體時序圖如圖6所示。

圖6 UMA 授權流程時序圖Fig.6 User authorization sequence diagram of UMA

4 整體功能設計

4.1 整體功能說明

基于OAuth2.0，OpenID Connect和UMA的用戶認證授權系統，將整合三者的功能，實現以授權服務器為身份提供者的單點登陸系統，實現用戶對客戶端應用授權訪問受保護的資源，以及實現用戶對其他用戶的客戶端應用進行授權的功能。本架構設計未指定實現時使用的語言以及數據庫的選型，即可以適用于各種語言和數據庫實現。客戶端和資源服務器在授權服務器的注冊與管理既可以使用靜態方式，也可以使用動態[7]方式。本架構使用 JWT作為令牌格式，并使用JWS[8]，JWE[9]和JWK[10]等配套技術保證JWT的安全。各組件關系圖如圖7所示。

圖7 系統組件視圖Fig.7 component view of system architecture

如圖7所示，本系統由授權服務器，授權數據庫，資源服務器，客戶端應用，日志監控平臺構成，本系統的使用者有資源擁有者以及訪問申請者兩類，特別的，如果資源擁有者和訪問申請者為同一人，本系統會自適應為基本的OAuth2.0系統。訪問申請者在客戶端和授權服務器的登陸使用 OpenID Connect進行單點登陸。資源擁有者在資源服務器和授權服務器的登陸也可以使用OpenID Connect進行單點登陸。授權服務器進行集群部署，日志監控平臺主要對授權服務器進行監控。授權數據庫在授權服務器集群看來是單個節點的數據庫，但數據庫自身可以采用集群部署，前提是選用的數據庫支持集群化。

4.2 安全性架構設計

基于 OAuth2.0框架的用戶認證授權系統可能會有一些潛在的安全風險，本架構嘗試從客戶端、授權服務器、資源服務器及令牌四個方面對這些潛在的安全風險進行分析，并給出解決方案[11]。

OAuth2.0客戶端安全架構首先要考慮的是基本安全問題，如客戶端密碼、授權碼和訪問令牌的保密。客戶端密碼的保密可以使用動態客戶端注冊，從而規避了在客戶端持久化客戶端密碼及多客戶端共享密碼的問題。授權碼、訪問令牌需要注意不能出現在任何的日志中，以及選擇不在客戶端持久化授權碼和訪問令牌。客戶端在授權碼流程中的授權碼請求中需要附上隨機生成的state值，并在授權服務器返回授權碼后校驗隨授權碼返回的state值是否相同，從而規避 CSRF[12]攻擊。在客戶端向資源服務器發起請求時，需要將訪問令牌放入Authorization Header中而不是請求參數中，降低令牌泄露的風險。客戶端在授權服務器注冊的回調地址需要盡可能精確，且如果一個客戶端注冊了多個授權服務器，則在各授權服務器上的回掉地址都必須唯一，以避免客戶端密碼的泄露。對原生應用客戶端而言，可以使用Reverse DNS Notation來確定回調地址，減少回掉地址沖突的可能性[13]。為避免授權碼被攔截，可以通過 PKCE[14]協議綁定授權碼請求與訪問令牌請求，確保兩個請求由同一個客戶端發起。

OAuth2.0資源服務器面對的首要安全風險是XSS[15]攻擊，降低此攻擊風險的措施首先是資源服務器不要支持除 Authorization Header之外的其他Token傳遞方式，然后是對請求返回結果的類型做具體的約束，并增加X-Content-Type-Options: nosniff和X-XSS-Protection: 1; mode=block兩個header。另外為了支持隱式授權流中對資源服務器的調用，需要在資源服務器中增加 CORS[16,17]支持。最后由于OAuth2.0框架需要全程使用 https協議，在資源服務器中可以通過增加 HSTS header[18]來強制瀏覽器通過https協議與資源服務器交互。

OAuth2.0授權服務器是整個基于 OAuth2.0的用戶認證授權系統的核心應用。授權服務器需要強制規定授權碼只能使用一次，若多次使用同一個授權碼，授權服務器必須拒絕并同時收回之前基于此授權碼簽發的所有訪問令牌。授權服務器需要確保使用授權碼請求訪問令牌的客戶端與當初請求授權碼的客戶端是同一個客戶端。為了避免由回掉地址引起的安全風險，授權服務器應使用精確匹配的方式驗證回調地址是否與配置的相同，并需要確定訪問令牌請求的回掉地址與授權碼請求的回掉地址相同。

授權令牌是基于 OAuth2.0的用戶認證授權系統的核心信息載體。主流的授權令牌類型是 Bearer Token，即任何持有該令牌的客戶端均可以調用該令牌允許的資源。對Bearer Token來說，其安全風險可以分類為令牌偽造，令牌重放，令牌重定向以及令牌信息泄露。由于Bearer Token的持有即可用的特點，Bearer Token的所有傳輸過程均必須使用點到點加密傳輸，如 TLS。在客戶端請求令牌時，建議請求最小的可用scope，如果基于用戶體驗考慮不能過度限制scope，則可以通過使用更新令牌重新獲取更小 scope的訪問令牌。在客戶端需要考慮令牌的安全保存，在沒有必要性的前提下不使用持久化保存訪問令牌。在授權服務器保存訪問令牌時，可以保存該令牌的Hash值而不是令牌本身，并在簽發訪問令牌時，限制令牌的有效期限在一次完整的API調用時長為宜。授權服務器需要實現完備的日志監控系統，對令牌的請求、簽發、使用、收回[19]時的上下文做詳盡的記錄，但需注意令牌本身不能出現在日志中。對資源服務器而言，一樣需要注意在日志中不能出現訪問令牌，在要求 scope時要求針對某個調用最低限的scope，考慮不把令牌保存在持久層，正確的驗證令牌的可用性，以及限制對API調用的調用數量和頻度從而避免DDOS攻擊和避免攻擊者反復猜測令牌。

由于本架構的授權服務器和資源服務器采用分布式架構，資源服務器與授權服務器無法做到數據庫共享，因此在Bearer Token的基礎上采用JWT向令牌的內容中注入相關的信息，使資源服務器可以對令牌做初步的解析，并使用JWS簽名來確保令牌的內容不被篡改，以及使用JWE加密來確保令牌的內容不會泄露。簽名和加密的算法均使用RS256非對稱加密，其中JWS簽名和JWE加密的加密方均為授權服務器，解密方均為資源服務器，區別在于JWS簽名使用授權服務器自身的密鑰，而JWE加密是使用資源服務器暴露的公鑰。選擇非對稱加密而不是對稱加密的主要原因是對稱加密將使得資源服務器同樣有能力獨力生成訪問令牌。在解析JWT進行初步驗證的基礎上，資源服務器依然需要調用授權服務器的令牌解析地址確認令牌的有效性以及查詢相關的敏感信息。同時，客戶端在必要時可以調用授權服務器的令牌回收地址主動回收授權令牌。

4.3 連通性及可擴展性架構設計

在基于OAuth2.0的用戶認證授權系統中，授權服務器、資源服務器和客戶端應用三者相互獨立，但在實際系統中，授權服務器和資源服務器的角色可以集中在單個應用中。這種高度耦合的結構適用于資源量少的情況，以及資源服務器和授權服務器由同一方提供的情況。在本架構的目標應用場景中，資源服務器可能并不是由授權服務器的提供方提供，同時資源服務器的數量可能會非常多，使得授權服務器和資源服務器合二為一不再合適。在授權服務器和資源服務器分散部署的前提下，授權服務器需要管理大量的資源服務器，為它們設置大量的客戶端id和客戶端密碼，這種管理方式隨著資源服務器的增加而復雜度迅速增長。更進一步，部分資源服務器是由第三方提供，這類資源服務器在授權服務器上的注冊如果采用靜態方式，則無論是資源服務器的新增還是配置的變更都將成為維護上的難題。在 UMA協議下，授權服務器甚至可能會需要資源服務器去動態的發現，無法通過靜態的方式進行配置。綜上得出的結論是需要資源服務器的動態注冊方案，通過用戶選擇或自動發現的方式動態配置授權服務器的信息后，再由資源服務器注冊自身到授權服務器。這是UMA協議的通用解決方案。

同樣的，客戶端應用在數量上會更加龐大，同時客戶端應用的提供者有更大的可能與授權服務器提供方不相同。同時客戶端應用的安全特性決定了保存在客戶端應用的常量有較大的泄露風險。為了使得客戶端應用在管理上可控并增強客戶端應用的安全性，客戶端在授權服務器上的注冊應當盡可能采用動態注冊方案。

4.4 性能及高可用性架構設計

在基于OAuth2.0的用戶認證授權系統中，資源服務器在收到客戶端應用的請求后，需要在初步判斷令牌有效后，調用授權服務器的令牌解析服務最終確定令牌的有效性。在默認的情況下，資源服務器每收到一個客戶端請求，都會調用一次授權服務器的令牌解析服務。這在訪問量巨大的情況下會帶來無法忽視的性能負擔。為了增強性能，資源服務器可以緩存令牌有效性信息，并在合適的時間點使緩存失效，從而在性能和安全性上取得平衡。

授權服務器作為基于 OAuth2.0的用戶認證授權系統的核心，其可用性至關重要。為了保證授權服務器在絕大多數時間都可用，需要進行集群部署。在本架構中，多臺授權服務器默認共享一個核心數據庫，各授權服務器的一次功能調用在數據庫端視為一個事務。由于授權服務器需要與用戶進行前端的交互，有部分數據會保存在Session中，為了使多臺授權服務器可以共同為同一個用戶服務，各授權服務器之間需要設置Session共享。

5 結論

本文介紹了 OAuth2.0授權框架，OpenID Connect協議和 UMA協議，并詳細說明了基于OAuth2.0，OpenID Connect和UMA的用戶認證授權系統的架構設計。該架構設計解決了用戶單點認證登陸，動態授權及用戶間授權等問題。該架構設計滿足了高度安全性，連通性，可擴展性，高性能及高可用性的架構設計目標，可以適用于廣泛的應用場景。

[1] E Hammerlahav. The OAuth2.0 Protocol. tools.ietf.org.

[2] M Jones, D Hardt. The OAuth 2.0 Authorization Framework:Bearer Token Usage. Ietf Rfc, 2012.

[3] E J. Richer. OAuth 2.0 Token Introspection. tools.ietf.org.

[4] DN Sakimura, J Bradley, M Jones. OpenID Connect Standard 1.0-draft 21. m1.archiveorange.com.

[5] MD Chen, HS Zhu, B Wang, QF Wen, C Institute. JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants. 《British Journal of Urology》,2013 , 54(6): 641–644.

[6] MP Machulak, EL Maler, D Catalano, AV Moorsel. Usermanaged access to web resources. Workshop on Digital Identity Management, 2010: 35-44.

[7] J Bradley，M Machulak，M Jones，J Richer. OAuth 2.0 Core Dynamic Client Registration. 《Pm Engineer》, 2013.

[8] M Jones， J Bradley, N Sakimura. JSON Web Signature(JWS). rfc-editor.org.

[9] J Hildebrand. JSON Web Encryption (JWE). rfc-editor.org.

[10] MBJ &Lt, M Com&Gt. JSON Web Key (JWK). rfc-editor.org.

[11] K Curran, E Ferry, JO Raw. Security evaluation of the OAuth 2.0 framework. 《Information & Computer Security》, 2015,23(1): 73-101.

[12] R Feil，L Nyffenegger. Evolution of cross site request forgery attacks. 《Journal in Computer Virology》, 2008, 4(1): 61-71.

[13] W Denniss, J Bradley. OAuth 2.0 for Native Apps. rfc-editor.org.

[14] E N. Sakimura, J Bradley, N Agarwal. Proof Key for Code Exchange by OAuth Public Clients. rfc-editor.org.

[15] P Vogt, F Nentwich, N Jovanovic, E Kirda, C Krügel, etc.Cross Site Scripting Prevention with Dynamic Data Tainting and Static Analysis. Network & Distributed System Security Symposium , 2007.

[16] H Saiedian, SB Dan. Security Vulnerabilities in the Same-Origin Policy: Implications and Alternatives. 《Computer》, 2011, 44(9): 29-36.

[17] A Van Kesteren. Cross-Origin Resource Sharing. Betascript Publishing, 2010.

[18] H Netze. HTTP Strict Transport Security (HSTS). HTTP Strict Transport Security (HSTS) draft-hodges-strict-transport- sec-02, 2012.

[19] M Scurtescu. OAuth 2.0 Token Revocation. rfc-editor.org.

System Architecture for User Authentication and Authorization Based of OAuth2.0, OpenID Connect and UMA

SHEN Tong, WANG Yong, LIU Jun-yan
(Beijing huitong jincai information technology co., LTD., Beijing 100053, China)

The basic function of a user authentication system is to prove a user is who he claims to be, and to manage the user’s basic information. The basic function of a user authorization system is to give user or application allowance to access protected resources. OAuth2.0 is a user authorization framework that enables client application to ask users to delegate to them the ability to access the user’s protected resources. OpenID Connect is a user authentication protocol based on OAuth2.0 framework. UMA is an authorization protocol based on OAuth2.0 that enables user to user authorization. This paper gives a comprehensive overview of the functionality of the aforementioned frameworks and tries to build a complete user authentication and authorization system based on those frameworks. The finished system architecture is functionally complete, has good security, connectivity, extensibility,availability and high performance.

User authentication; User authorization; OAuth2.0; OpenID connect; UMA

TP393.08

A

10.3969/j.issn.1003-6970.2017.11.031

本文著錄格式：沈桐，王勇，劉俊艷. 基于OAuth2.0, OpenID Connect和UMA的用戶認證授權系統架構[J]. 軟件，2017，38（11）：160-167

沈桐(1984-)，男，北京匯通金財信息科技有限公司，主要研究方向：互聯網技術；王勇(1982-)，男，北京匯通金財信息科技有限公司，主要研究方向：互聯網+電力營銷服務，互聯網技術；劉俊艷(1978-)，女，北京匯通金財信息科技有限公司，主要研究方向：計算機應用。