基于OAuth2.0, OpenID Connect和UMA的用戶認(rèn)證授權(quán)系統(tǒng)架構(gòu)

沈 桐，王 勇，劉俊艷

（北京匯通金財(cái)信息科技有限公司，北京 100053）

基于OAuth2.0, OpenID Connect和UMA的用戶認(rèn)證授權(quán)系統(tǒng)架構(gòu)

沈 桐，王 勇，劉俊艷

（北京匯通金財(cái)信息科技有限公司，北京 100053）

用戶認(rèn)證系統(tǒng)的基本功能是用來證明一個(gè)用戶是他聲稱的那個(gè)用戶，并管理該用戶相關(guān)的基本信息。用戶授權(quán)系統(tǒng)的基本功能是授予用戶或應(yīng)用權(quán)限訪問受保護(hù)的資源。OAuth2.0是一個(gè)用戶授權(quán)框架，該框架提供了使客戶端應(yīng)用可以請(qǐng)求用戶授權(quán)該應(yīng)用訪問該用戶受保護(hù)的資源的功能。OpenID Connect是基于OAuth2.0框架的用戶身份認(rèn)證協(xié)議。UMA是基于OAuth2.0框架的用戶間授權(quán)協(xié)議。本文介紹了上述框架和協(xié)議的功能與實(shí)現(xiàn)，并整合三者嘗試搭建完整的用戶認(rèn)證授權(quán)系統(tǒng)，使該系統(tǒng)架構(gòu)具備功能上的完備性，良好的安全性，靈活的連通性，可擴(kuò)展性，高性能以及高可用性。

用戶認(rèn)證；用戶授權(quán)；OAuth2.0；OpenID Connect；UMA

0 用戶認(rèn)證授權(quán)簡述

用戶認(rèn)證系統(tǒng)的解決的核心問題是“確定用戶是他聲稱自己是的那個(gè)人”。用戶授權(quán)系統(tǒng)解決的核心問題是“用戶如何獲取權(quán)限來訪問受保護(hù)的資源”。用戶認(rèn)證不一定發(fā)生在用戶授權(quán)之前，因?yàn)橐粋€(gè)未認(rèn)證的匿名用戶也可能能夠獲取一定的受限制的權(quán)限。對(duì)網(wǎng)絡(luò)應(yīng)用來說，常見的用戶認(rèn)證系統(tǒng)的實(shí)現(xiàn)方式是用戶使用用戶名和密碼在網(wǎng)絡(luò)應(yīng)用提供的頁面進(jìn)行登陸，網(wǎng)絡(luò)應(yīng)用把用戶提供的信息與自身管理的用戶數(shù)據(jù)庫中的信息進(jìn)行比對(duì)來進(jìn)行認(rèn)證。網(wǎng)絡(luò)應(yīng)用的數(shù)量的爆炸性增長催生了對(duì)單點(diǎn)登陸系統(tǒng)的需求。而常見的授權(quán)系統(tǒng)則包括應(yīng)用A直接拿著用戶的密碼等信息、模仿用戶訪問應(yīng)用B下受保護(hù)的資源。這種授權(quán)方式的弊端很多，包括用戶密碼等敏感信息的泄露風(fēng)險(xiǎn)，以及應(yīng)用B無法區(qū)分應(yīng)用A與用戶自身究竟是誰在發(fā)起訪問等。

1 OAuth2.0簡述

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

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

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

2 OpenID Connect簡述

OpenID Connect是基于 OAuth2.0框架的用戶認(rèn)證協(xié)議[4]。OpenID Connect解決的基本問題是允許客戶端能夠使用用戶在授權(quán)服務(wù)器進(jìn)行的身份認(rèn)證作為自身系統(tǒng)的身份認(rèn)證，以及允許客戶端通過簡單的 Restful風(fēng)格的網(wǎng)絡(luò)調(diào)用獲取用戶的基本信息?；贠penID Connect的用戶認(rèn)證系統(tǒng)本質(zhì)上是以 OAuth2.0授權(quán)服務(wù)器作為登陸點(diǎn)的單點(diǎn)登陸系統(tǒng)。基于OpenID Connect的用戶認(rèn)證系統(tǒng)組件視圖如圖3所示。

如圖3所示，OpenID Connect用戶認(rèn)證系統(tǒng)的基本組成部分為用戶，客戶端應(yīng)用，身份提供者三部分。其中用戶與客戶端應(yīng)用完全對(duì)應(yīng)OAuth2.0中的同名組件，而OAuth2.0框架中的授權(quán)服務(wù)器和資源服務(wù)器共同組成此處的身份提供者?；贠penID Connect的用戶認(rèn)證系統(tǒng)的標(biāo)準(zhǔn)流程為用戶嘗試在客戶端應(yīng)用登陸，客戶端應(yīng)用將用戶引導(dǎo)至身份提供者頁面，用戶在身份提供者登陸后授權(quán)客戶端應(yīng)用使用該用戶的身份登陸，身份提供者將OAuth2.0訪問令牌以及一個(gè)包含用戶基本登陸信息的 JWT令牌[5]——ID Token返回給客戶端，客戶端解析ID Token并驗(yàn)證有效后認(rèn)為用戶在客戶端登陸，并持令牌訪問身份提供者獲取用戶的詳細(xì)信息。具體流程時(shí)序圖如圖4所示。

3 UMA 簡述

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

圖2 OAuth2.0授權(quán)碼流程時(shí)序圖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用戶登陸時(shí)序圖Fig.4 User login sequence diagram of OpenID Connect

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

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

圖6 UMA 授權(quán)流程時(shí)序圖Fig.6 User authorization sequence diagram of UMA

4 整體功能設(shè)計(jì)

4.1 整體功能說明

基于OAuth2.0，OpenID Connect和UMA的用戶認(rèn)證授權(quán)系統(tǒng)，將整合三者的功能，實(shí)現(xiàn)以授權(quán)服務(wù)器為身份提供者的單點(diǎn)登陸系統(tǒng)，實(shí)現(xiàn)用戶對(duì)客戶端應(yīng)用授權(quán)訪問受保護(hù)的資源，以及實(shí)現(xiàn)用戶對(duì)其他用戶的客戶端應(yīng)用進(jìn)行授權(quán)的功能。本架構(gòu)設(shè)計(jì)未指定實(shí)現(xiàn)時(shí)使用的語言以及數(shù)據(jù)庫的選型，即可以適用于各種語言和數(shù)據(jù)庫實(shí)現(xiàn)?？蛻舳撕唾Y源服務(wù)器在授權(quán)服務(wù)器的注冊(cè)與管理既可以使用靜態(tài)方式，也可以使用動(dòng)態(tài)[7]方式。本架構(gòu)使用 JWT作為令牌格式，并使用JWS[8]，JWE[9]和JWK[10]等配套技術(shù)保證JWT的安全。各組件關(guān)系圖如圖7所示。

圖7 系統(tǒng)組件視圖Fig.7 component view of system architecture

如圖7所示，本系統(tǒng)由授權(quán)服務(wù)器，授權(quán)數(shù)據(jù)庫，資源服務(wù)器，客戶端應(yīng)用，日志監(jiān)控平臺(tái)構(gòu)成，本系統(tǒng)的使用者有資源擁有者以及訪問申請(qǐng)者兩類，特別的，如果資源擁有者和訪問申請(qǐng)者為同一人，本系統(tǒng)會(huì)自適應(yīng)為基本的OAuth2.0系統(tǒng)。訪問申請(qǐng)者在客戶端和授權(quán)服務(wù)器的登陸使用 OpenID Connect進(jìn)行單點(diǎn)登陸。資源擁有者在資源服務(wù)器和授權(quán)服務(wù)器的登陸也可以使用OpenID Connect進(jìn)行單點(diǎn)登陸。授權(quán)服務(wù)器進(jìn)行集群部署，日志監(jiān)控平臺(tái)主要對(duì)授權(quán)服務(wù)器進(jìn)行監(jiān)控。授權(quán)數(shù)據(jù)庫在授權(quán)服務(wù)器集群看來是單個(gè)節(jié)點(diǎn)的數(shù)據(jù)庫，但數(shù)據(jù)庫自身可以采用集群部署，前提是選用的數(shù)據(jù)庫支持集群化。

4.2 安全性架構(gòu)設(shè)計(jì)

基于 OAuth2.0框架的用戶認(rèn)證授權(quán)系統(tǒng)可能會(huì)有一些潛在的安全風(fēng)險(xiǎn)，本架構(gòu)嘗試從客戶端、授權(quán)服務(wù)器、資源服務(wù)器及令牌四個(gè)方面對(duì)這些潛在的安全風(fēng)險(xiǎn)進(jìn)行分析，并給出解決方案[11]。

OAuth2.0客戶端安全架構(gòu)首先要考慮的是基本安全問題，如客戶端密碼、授權(quán)碼和訪問令牌的保密?？蛻舳嗣艽a的保密可以使用動(dòng)態(tài)客戶端注冊(cè)，從而規(guī)避了在客戶端持久化客戶端密碼及多客戶端共享密碼的問題。授權(quán)碼、訪問令牌需要注意不能出現(xiàn)在任何的日志中，以及選擇不在客戶端持久化授權(quán)碼和訪問令牌?？蛻舳嗽谑跈?quán)碼流程中的授權(quán)碼請(qǐng)求中需要附上隨機(jī)生成的state值，并在授權(quán)服務(wù)器返回授權(quán)碼后校驗(yàn)隨授權(quán)碼返回的state值是否相同，從而規(guī)避 CSRF[12]攻擊。在客戶端向資源服務(wù)器發(fā)起請(qǐng)求時(shí)，需要將訪問令牌放入Authorization Header中而不是請(qǐng)求參數(shù)中，降低令牌泄露的風(fēng)險(xiǎn)?？蛻舳嗽谑跈?quán)服務(wù)器注冊(cè)的回調(diào)地址需要盡可能精確，且如果一個(gè)客戶端注冊(cè)了多個(gè)授權(quán)服務(wù)器，則在各授權(quán)服務(wù)器上的回掉地址都必須唯一，以避免客戶端密碼的泄露。對(duì)原生應(yīng)用客戶端而言，可以使用Reverse DNS Notation來確定回調(diào)地址，減少回掉地址沖突的可能性[13]。為避免授權(quán)碼被攔截，可以通過 PKCE[14]協(xié)議綁定授權(quán)碼請(qǐng)求與訪問令牌請(qǐng)求，確保兩個(gè)請(qǐng)求由同一個(gè)客戶端發(fā)起。

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

OAuth2.0授權(quán)服務(wù)器是整個(gè)基于 OAuth2.0的用戶認(rèn)證授權(quán)系統(tǒng)的核心應(yīng)用。授權(quán)服務(wù)器需要強(qiáng)制規(guī)定授權(quán)碼只能使用一次，若多次使用同一個(gè)授權(quán)碼，授權(quán)服務(wù)器必須拒絕并同時(shí)收回之前基于此授權(quán)碼簽發(fā)的所有訪問令牌。授權(quán)服務(wù)器需要確保使用授權(quán)碼請(qǐng)求訪問令牌的客戶端與當(dāng)初請(qǐng)求授權(quán)碼的客戶端是同一個(gè)客戶端。為了避免由回掉地址引起的安全風(fēng)險(xiǎn)，授權(quán)服務(wù)器應(yīng)使用精確匹配的方式驗(yàn)證回調(diào)地址是否與配置的相同，并需要確定訪問令牌請(qǐng)求的回掉地址與授權(quán)碼請(qǐng)求的回掉地址相同。

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

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

4.3 連通性及可擴(kuò)展性架構(gòu)設(shè)計(jì)

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

同樣的，客戶端應(yīng)用在數(shù)量上會(huì)更加龐大，同時(shí)客戶端應(yīng)用的提供者有更大的可能與授權(quán)服務(wù)器提供方不相同。同時(shí)客戶端應(yīng)用的安全特性決定了保存在客戶端應(yīng)用的常量有較大的泄露風(fēng)險(xiǎn)。為了使得客戶端應(yīng)用在管理上可控并增強(qiáng)客戶端應(yīng)用的安全性，客戶端在授權(quán)服務(wù)器上的注冊(cè)應(yīng)當(dāng)盡可能采用動(dòng)態(tài)注冊(cè)方案。

4.4 性能及高可用性架構(gòu)設(shè)計(jì)

在基于OAuth2.0的用戶認(rèn)證授權(quán)系統(tǒng)中，資源服務(wù)器在收到客戶端應(yīng)用的請(qǐng)求后，需要在初步判斷令牌有效后，調(diào)用授權(quán)服務(wù)器的令牌解析服務(wù)最終確定令牌的有效性。在默認(rèn)的情況下，資源服務(wù)器每收到一個(gè)客戶端請(qǐng)求，都會(huì)調(diào)用一次授權(quán)服務(wù)器的令牌解析服務(wù)。這在訪問量巨大的情況下會(huì)帶來無法忽視的性能負(fù)擔(dān)。為了增強(qiáng)性能，資源服務(wù)器可以緩存令牌有效性信息，并在合適的時(shí)間點(diǎn)使緩存失效，從而在性能和安全性上取得平衡。

授權(quán)服務(wù)器作為基于 OAuth2.0的用戶認(rèn)證授權(quán)系統(tǒng)的核心，其可用性至關(guān)重要。為了保證授權(quán)服務(wù)器在絕大多數(shù)時(shí)間都可用，需要進(jìn)行集群部署。在本架構(gòu)中，多臺(tái)授權(quán)服務(wù)器默認(rèn)共享一個(gè)核心數(shù)據(jù)庫，各授權(quán)服務(wù)器的一次功能調(diào)用在數(shù)據(jù)庫端視為一個(gè)事務(wù)。由于授權(quán)服務(wù)器需要與用戶進(jìn)行前端的交互，有部分?jǐn)?shù)據(jù)會(huì)保存在Session中，為了使多臺(tái)授權(quán)服務(wù)器可以共同為同一個(gè)用戶服務(wù)，各授權(quán)服務(wù)器之間需要設(shè)置Session共享。

5 結(jié)論

本文介紹了 OAuth2.0授權(quán)框架，OpenID Connect協(xié)議和 UMA協(xié)議，并詳細(xì)說明了基于OAuth2.0，OpenID Connect和UMA的用戶認(rèn)證授權(quán)系統(tǒng)的架構(gòu)設(shè)計(jì)。該架構(gòu)設(shè)計(jì)解決了用戶單點(diǎn)認(rèn)證登陸，動(dòng)態(tài)授權(quán)及用戶間授權(quán)等問題。該架構(gòu)設(shè)計(jì)滿足了高度安全性，連通性，可擴(kuò)展性，高性能及高可用性的架構(gòu)設(shè)計(jì)目標(biāo)，可以適用于廣泛的應(yīng)用場景。

[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的用戶認(rèn)證授權(quán)系統(tǒng)架構(gòu)[J]. 軟件，2017，38（11）：160-167

沈桐(1984-)，男，北京匯通金財(cái)信息科技有限公司，主要研究方向：互聯(lián)網(wǎng)技術(shù)；王勇(1982-)，男，北京匯通金財(cái)信息科技有限公司，主要研究方向：互聯(lián)網(wǎng)+電力營銷服務(wù)，互聯(lián)網(wǎng)技術(shù)；劉俊艷(1978-)，女，北京匯通金財(cái)信息科技有限公司，主要研究方向：計(jì)算機(jī)應(yīng)用。