基于OAuth2.0協議的單點登錄系統研究與實現

林彬彬 李 超

1.中國電建華東勘測設計研究院有限公司 浙江 杭州 311122 2.浙江華東工程數字技術有限公司 浙江 杭州 311122

0 引言

隨著企業網絡信息化的建設,大多數企業會根據不同的業務構建出不同的應用系統,這些應用系統在不同的時間節點使用不同的開發技術完成,不同的應用系統之間的資源無法共享。每使用一個系統都需要輸入用戶名、密碼登錄。操作非常不方便,而且頻繁輸入用戶名和密碼容易造成用戶信息的泄露,降低系統的安全性。

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

1 單點登錄技術發展與應用

OAuth2.0是用來允許用戶授權第三方應用訪問他在另一個服務器資源的一種協議,OAuth2.0在客戶端與服務提供商之間,設置了一個授權層(authorization layer)。客戶端不能直接登錄服務提供商,只能登錄授權層,以此將用戶與客戶端區分開來。然后客戶端在登錄時候不使用賬號密碼,而是使用會自動過期的令牌token?？蛻舳说卿浭跈鄬右院?服務提供商根據令牌的權限范圍和有效期,向客戶端開放用戶儲存的資料。OAuth2.0主要涉及四個對象:

(1)Client第三方應用,我們的應用就是一個Client;

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

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

(4)Resource Server擁有資源信息的服務器,通常和授權服務器屬于同一應用。

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

圖1 OAuth2.0工作原理

其步驟如下:

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

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

(3)客戶端使用上一步獲得的授權,向認證服務器申請令牌。

(4)認證服務器對客戶端進行認證以后,確認無誤,同意發放令牌。

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

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

2 OAuth2.0工作模式

OAuth 2.0定義了四種授權模式,授權許可類型取決于應用請求授權的方式和授權方支持的授權模式,每一種都有適用的應用場景。

2.1 授權碼模式 授權碼模式(authorization code)是功能最完整、流程最嚴密的授權模式。它的特點就是通過客戶端的后臺服務器,與“服務提供商”的認證服務器進行互動。授權碼模式步驟如下:

(1)用戶訪問客戶端,后者將前者導向認證服務器;

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

(3)假設用戶給予授權,認證服務器將用戶導向客戶端事先指定的“重定向 URI”(redirection URI),同時附上一個授權碼;

(4)客戶端收到授權碼,附上早先的“重定向URI”,向認證服務器申請令牌。這一步是在客戶端的后臺的服務器上完成的,對用戶不可見;

(5)認證服務器核對了授權碼和重定向URI,確認無誤后,向客戶端發送訪問令牌(access token)和更新令牌(refresh token);

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

(1)客戶端將用戶導向認證服務器;

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

(3)假設用戶給予授權,認證服務器將用戶導向客戶端指定的“重定向URI”,并在URI的Hash部分包含了訪問令牌;

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

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

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

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

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

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

(2)客戶端將用戶名和密碼發給認證服務器,向后者請求令牌;

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

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

(1)客戶端向認證服務器進行身份認證,并要求一個訪問令牌;

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

2.5 工作模式應用場景

表格1 授權模式對比

3 單點登錄實現

在某防汛數字化平臺項目中,平臺負責管理各個應用系統訪問入口,將各應用系統的身份認證功能集中控制。實現用戶在門戶平臺認證通過后,無需二次認證,即可訪問其他應用系統的效果[3]。由于平臺接入第三方應用較多,涉及不同的技術架構,而且平臺與第三方間需要共享數據,故采用授權碼模式進行授權認證,實現了單點登錄系統。平臺單點登錄流程示意圖如下:

圖6 單點登錄流程示意圖

平臺作為SSO認證中心,負責處理客戶端的請求,發放授權碼。業務系統SSO客戶端拿到授權碼后根據平臺提供的SDK生成含應用信息的令牌,用來訪問受保護的資源。第三方客戶端單點登錄接入步驟:

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

(2)用戶對應用進行授權用戶可選擇同意授權或拒絕授權,第三方網站應該做好拒絕提示頁面。

(3)平臺認證服務器通過回調地址{redirect_uri}將用戶授權碼傳遞給應用服務器或者直接在Webview中跳轉到攜帶用戶授權碼的回調地址({redirect_uri}?code=abc&state=xyz)

(4)應用服務器或Webview使用access_token API向平臺認證服務器發送post請求傳入用戶授權碼以及回調地址(POST請求)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)平臺認證服務器返回access_token應用通過access_token訪問Open API使用用戶數據。

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

應用效果評價:平臺通過該單點登錄系統,實現了17個外部系統無縫集成,滿足了第三方應用外鏈跳轉及頁面框架內部集成等多種單點登錄訪問方式,完成了對相關業務系統的集成整合工作。

4 結語

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