基于OAuth2.0協(xié)議的單點(diǎn)登錄系統(tǒng)研究與實(shí)現(xiàn)

林彬彬 李 超

1.中國電建華東勘測(cè)設(shè)計(jì)研究院有限公司 浙江 杭州 311122 2.浙江華東工程數(shù)字技術(shù)有限公司 浙江 杭州 311122

0 引言

隨著企業(yè)網(wǎng)絡(luò)信息化的建設(shè),大多數(shù)企業(yè)會(huì)根據(jù)不同的業(yè)務(wù)構(gòu)建出不同的應(yīng)用系統(tǒng),這些應(yīng)用系統(tǒng)在不同的時(shí)間節(jié)點(diǎn)使用不同的開發(fā)技術(shù)完成,不同的應(yīng)用系統(tǒng)之間的資源無法共享。每使用一個(gè)系統(tǒng)都需要輸入用戶名、密碼登錄。操作非常不方便,而且頻繁輸入用戶名和密碼容易造成用戶信息的泄露,降低系統(tǒng)的安全性。

為了解決這個(gè)問題,應(yīng)該將企業(yè)內(nèi)部的各個(gè)應(yīng)用系統(tǒng)集成到一個(gè)門戶系統(tǒng)之上,用戶只需要初始進(jìn)行一次登錄和身份認(rèn)證,就可以訪問具有權(quán)限的任何系統(tǒng),而不需要再次登錄[2]。這一技術(shù)稱作單點(diǎn)登錄技術(shù),它是企業(yè)進(jìn)行資源信息整合時(shí)最常用使用的解決方案。傳統(tǒng)的單點(diǎn)登錄系統(tǒng)中要求第三方系統(tǒng)中保存用戶名、密碼等信息,要求對(duì)接入單點(diǎn)登錄系統(tǒng)的第三方平臺(tái)進(jìn)行授權(quán)驗(yàn)證。OAuth為資源授權(quán)提供了一個(gè)開放標(biāo)準(zhǔn),允許用戶授權(quán)第三方應(yīng)用訪問他們存儲(chǔ)在另外的服務(wù)提供者上的信息,而不需要將用戶名和密碼提供給第三方應(yīng)用或分享他們數(shù)據(jù)的所有內(nèi)容。OAuth2.0是OAuth協(xié)議的延續(xù)版本,它可以為web應(yīng)用、桌面應(yīng)用、移動(dòng)應(yīng)用提供授權(quán)流程。

1 單點(diǎn)登錄技術(shù)發(fā)展與應(yīng)用

OAuth2.0是用來允許用戶授權(quán)第三方應(yīng)用訪問他在另一個(gè)服務(wù)器資源的一種協(xié)議,OAuth2.0在客戶端與服務(wù)提供商之間,設(shè)置了一個(gè)授權(quán)層(authorization layer)。客戶端不能直接登錄服務(wù)提供商,只能登錄授權(quán)層,以此將用戶與客戶端區(qū)分開來。然后客戶端在登錄時(shí)候不使用賬號(hào)密碼,而是使用會(huì)自動(dòng)過期的令牌token。客戶端登錄授權(quán)層以后,服務(wù)提供商根據(jù)令牌的權(quán)限范圍和有效期,向客戶端開放用戶儲(chǔ)存的資料。OAuth2.0主要涉及四個(gè)對(duì)象:

(1)Client第三方應(yīng)用,我們的應(yīng)用就是一個(gè)Client;

(2)Resource Owner資源所有者,即用戶;

(3)Authorization Server授權(quán)服務(wù)器,即提供第三方登錄服務(wù)的服務(wù)器;

(4)Resource Server擁有資源信息的服務(wù)器,通常和授權(quán)服務(wù)器屬于同一應(yīng)用。

OAuth2.0工作原理如下圖所示:

圖1 OAuth2.0工作原理

其步驟如下:

(1)用戶打開客戶端以后,客戶端要求用戶給予授權(quán)。

(2)用戶同意給予客戶端授權(quán)。

(3)客戶端使用上一步獲得的授權(quán),向認(rèn)證服務(wù)器申請(qǐng)令牌。

(4)認(rèn)證服務(wù)器對(duì)客戶端進(jìn)行認(rèn)證以后,確認(rèn)無誤,同意發(fā)放令牌。

(5)客戶端使用令牌,向資源服務(wù)器申請(qǐng)獲取資源。

(6)資源服務(wù)器確認(rèn)令牌無誤,同意向客戶端開放資源

2 OAuth2.0工作模式

OAuth 2.0定義了四種授權(quán)模式,授權(quán)許可類型取決于應(yīng)用請(qǐng)求授權(quán)的方式和授權(quán)方支持的授權(quán)模式,每一種都有適用的應(yīng)用場(chǎng)景。

2.1 授權(quán)碼模式 授權(quán)碼模式(authorization code)是功能最完整、流程最嚴(yán)密的授權(quán)模式。它的特點(diǎn)就是通過客戶端的后臺(tái)服務(wù)器,與“服務(wù)提供商”的認(rèn)證服務(wù)器進(jìn)行互動(dòng)。授權(quán)碼模式步驟如下:

(1)用戶訪問客戶端,后者將前者導(dǎo)向認(rèn)證服務(wù)器;

(2)用戶選擇是否給予客戶端授權(quán);

(3)假設(shè)用戶給予授權(quán),認(rèn)證服務(wù)器將用戶導(dǎo)向客戶端事先指定的“重定向 URI”(redirection URI),同時(shí)附上一個(gè)授權(quán)碼;

(4)客戶端收到授權(quán)碼,附上早先的“重定向URI”,向認(rèn)證服務(wù)器申請(qǐng)令牌。這一步是在客戶端的后臺(tái)的服務(wù)器上完成的,對(duì)用戶不可見;

(5)認(rèn)證服務(wù)器核對(duì)了授權(quán)碼和重定向URI,確認(rèn)無誤后,向客戶端發(fā)送訪問令牌(access token)和更新令牌(refresh token);

2.2 簡(jiǎn)化模式 簡(jiǎn)化模式(implicit grant type)不通過第三方應(yīng)用程序的服務(wù)器,直接在瀏覽器中向認(rèn)證服務(wù)器申請(qǐng)令牌,跳過了"授權(quán)碼"這個(gè)步驟。所有步驟在瀏覽器中完成,令牌對(duì)訪問者是可見的,且客戶端不需要認(rèn)證。簡(jiǎn)化模式步驟如下:

(1)客戶端將用戶導(dǎo)向認(rèn)證服務(wù)器;

(2)用戶決定是否給于客戶端授權(quán);

(3)假設(shè)用戶給予授權(quán),認(rèn)證服務(wù)器將用戶導(dǎo)向客戶端指定的“重定向URI”,并在URI的Hash部分包含了訪問令牌;

(4)瀏覽器向資源服務(wù)器發(fā)出請(qǐng)求,其中不包括上一步收到的Hash值;

(5)資源服務(wù)器返回一個(gè)網(wǎng)頁,其中包含的代碼可以獲取Hash值中的令牌;

(6)瀏覽器執(zhí)行上一步獲得的腳本,提取出令牌;

(7)瀏覽器將令牌發(fā)給客戶端;

2.3 密碼模式 密碼模式中,用戶向客戶端提供自己的用戶名和密碼。客戶端使用這些信息,向“服務(wù)商提供商”索要授權(quán)。在這種模式中,用戶必須把自己的密碼給客戶端,但是客戶端不得儲(chǔ)存密碼。這通常用在用戶對(duì)客戶端高度信任的情況下,比如客戶端是操作系統(tǒng)的一部分,或者由一個(gè)著名公司出品。而認(rèn)證服務(wù)器只有在其他授權(quán)模式無法執(zhí)行的情況下,才能考慮使用這種模式。密碼模式步驟如下:

(1)用戶向客戶端提供用戶名和密碼;

(2)客戶端將用戶名和密碼發(fā)給認(rèn)證服務(wù)器,向后者請(qǐng)求令牌;

(3)認(rèn)證服務(wù)器確認(rèn)無誤后,向客戶端提供訪問令牌;

2.4 客戶端模式 客戶端模式(Client Credentials Grant)指客戶端以自己的名義,而不是以用戶的名義,向“服務(wù)提供商”進(jìn)行認(rèn)證。在這種模式中,用戶直接向客戶端注冊(cè),客戶端以自己的名義要求“服務(wù)提供商”提供服務(wù),其實(shí)不存在授權(quán)問題。客戶端模式步驟

(1)客戶端向認(rèn)證服務(wù)器進(jìn)行身份認(rèn)證,并要求一個(gè)訪問令牌;

(2)認(rèn)證服務(wù)器確認(rèn)無誤后,向客戶端提供訪問令牌;

2.5 工作模式應(yīng)用場(chǎng)景

表格1 授權(quán)模式對(duì)比

3 單點(diǎn)登錄實(shí)現(xiàn)

在某防汛數(shù)字化平臺(tái)項(xiàng)目中,平臺(tái)負(fù)責(zé)管理各個(gè)應(yīng)用系統(tǒng)訪問入口,將各應(yīng)用系統(tǒng)的身份認(rèn)證功能集中控制。實(shí)現(xiàn)用戶在門戶平臺(tái)認(rèn)證通過后,無需二次認(rèn)證,即可訪問其他應(yīng)用系統(tǒng)的效果[3]。由于平臺(tái)接入第三方應(yīng)用較多,涉及不同的技術(shù)架構(gòu),而且平臺(tái)與第三方間需要共享數(shù)據(jù),故采用授權(quán)碼模式進(jìn)行授權(quán)認(rèn)證,實(shí)現(xiàn)了單點(diǎn)登錄系統(tǒng)。平臺(tái)單點(diǎn)登錄流程示意圖如下:

圖6 單點(diǎn)登錄流程示意圖

平臺(tái)作為SSO認(rèn)證中心,負(fù)責(zé)處理客戶端的請(qǐng)求,發(fā)放授權(quán)碼。業(yè)務(wù)系統(tǒng)SSO客戶端拿到授權(quán)碼后根據(jù)平臺(tái)提供的SDK生成含應(yīng)用信息的令牌,用來訪問受保護(hù)的資源。第三方客戶端單點(diǎn)登錄接入步驟:

(1)應(yīng)用通過瀏覽器或Webview將用戶引導(dǎo)到第三方認(rèn)證頁面上(GET請(qǐng)求)https://domain.com/v1/oauth/authorize?client_id={client_id}&redirect_uri={redirect_uri}&response_type=code

(2)用戶對(duì)應(yīng)用進(jìn)行授權(quán)用戶可選擇同意授權(quán)或拒絕授權(quán),第三方網(wǎng)站應(yīng)該做好拒絕提示頁面。

(3)平臺(tái)認(rèn)證服務(wù)器通過回調(diào)地址{redirect_uri}將用戶授權(quán)碼傳遞給應(yīng)用服務(wù)器或者直接在Webview中跳轉(zhuǎn)到攜帶用戶授權(quán)碼的回調(diào)地址({redirect_uri}?code=abc&state=xyz)

(4)應(yīng)用服務(wù)器或Webview使用access_token API向平臺(tái)認(rèn)證服務(wù)器發(fā)送post請(qǐng)求傳入用戶授權(quán)碼以及回調(diào)地址(POST請(qǐng)求)https://domain.com/v1/oauth/token?grant_type=authorization_code&code={code}&client_id={client_id}&redirect_uri={redirect_uri}&client_secret={client_secret}

(5)平臺(tái)認(rèn)證服務(wù)器返回access_token應(yīng)用通過access_token訪問Open API使用用戶數(shù)據(jù)。

(6)當(dāng)access_token過期后,通過以下refresh_token方式重新獲取access_token(POST請(qǐng)求)https://domain.com/v1/oauth/token?grant_type=refresh_token&refresh_token={refresh_token}

應(yīng)用效果評(píng)價(jià):平臺(tái)通過該單點(diǎn)登錄系統(tǒng),實(shí)現(xiàn)了17個(gè)外部系統(tǒng)無縫集成,滿足了第三方應(yīng)用外鏈跳轉(zhuǎn)及頁面框架內(nèi)部集成等多種單點(diǎn)登錄訪問方式,完成了對(duì)相關(guān)業(yè)務(wù)系統(tǒng)的集成整合工作。

4 結(jié)語

本文針對(duì)信息化建設(shè)過程中出現(xiàn)的各應(yīng)用系統(tǒng)用戶系統(tǒng)獨(dú)立、身份認(rèn)證系統(tǒng)獨(dú)立的現(xiàn)狀,提出了在確保各應(yīng)用系統(tǒng)正常運(yùn)行不受打擾的前提下,利用單點(diǎn)登錄技術(shù)解決所述問題的思路。深入研究OAuth2.0協(xié)議工作原理,分析了授權(quán)模式選型應(yīng)用場(chǎng)景。最后結(jié)合實(shí)際項(xiàng)目案例,實(shí)現(xiàn)了基于OAuth授權(quán)碼模式的單點(diǎn)登錄系統(tǒng),并在項(xiàng)目中取得高度認(rèn)可,可以在行業(yè)內(nèi)部以及其他行業(yè)推廣應(yīng)用。