OAuth2.0接口設計論文范文

本站小編為你精心準備了OAuth2.0接口設計論文參考范文，愿這些范文能點燃您思維的火花，激發您的寫作靈感。歡迎深入閱讀并收藏。

1.oauth2.0協議流程

在OAuth2.0中，客戶端通過訪問令牌來訪問受保護資源，其認證流程如圖1所示，總共有如下三個階段。（1）客戶端向資源擁有者申請獲得授權，申請可以直接發往資源擁有者，也可以通過授權服務器為中介（步驟1），資源擁有者許可授權，并向客戶端發送授權許可（步驟2），授權許可代表著資源擁有者授權的憑證，可以是四種標準許可類型（或擴展許可類型）中的一種；（2）客戶端通過與授權服務器進行認證，并出示授權許可來申請訪問令牌（步驟3），授權服務器與客戶端完成認證并確保授權許可合法性，向客戶端頒發訪問令牌（步驟4）；（3）客戶端向資源服務器出示訪問令牌來申請對受保護資源的訪問（步驟5），資源服務器驗證訪問令牌的合法性，向客戶端提供服務（步驟6）。

1.1獲得授權許可此階段的目的是為了獲得授權許可，標準定義的四種基本授權許可類型分別為授權碼、隱式、資源擁有者口令憑證和客戶端憑證，此外用戶可以自定義擴展的授權許可類型。授權過程中需要利用兩個服務接口：授權接口和令牌接口，客戶端使用授權接口通過用戶重定向從資源擁有者獲得授權，另外客戶端使用令牌接口來獲得訪問令牌。為了獲得授權許可，客戶端需要在HTTP請求中加入所需的參數并將請求發往授權接口，這些參數包括response_type、client_id、redirect_uri、scope和state。client_id是一個獨一無二的客戶端標識符，在客戶端注冊時頒發客戶端標識符，同時還頒發客戶端機密（client_secret），客戶端標識符不能單獨用于客戶端認證。redirect_uri是重定向接口，客戶端注冊時需要設置該接口，授權服務器通過使用重定向接口將資源服務器用戶回送到客戶端。scope是訪問請求的作用域，如果客戶端忽略該值，授權服務器必須使用預定義的默認作用域。state被客戶端用于維護請求狀態。當授權許可類型是授權碼時，response_type參數的值必須為code。當授權碼類型是隱式時，response_type的值為token。當授權碼類型為資源擁有者口令憑證時，response_type的值為psword，客戶端必須向服務器提交客戶標志、客戶端標識符和客戶端機密。當授權碼類型為客戶端憑證時，客戶端只需要將值為client_credentials的response_type參數發送。當客戶端使用授權碼許可類型且資源擁有者批準授權請求，需要在給客戶端的應答中頒發授權碼，應答中可能包含的參數有code和state。code是授權服務器生成的授權碼，為了降低安全風險，授權碼必須在頒發后盡快失效，規范中推薦授權碼最大生存時間為10min。在客戶端授權請求時如指定了state，則授權服務器的應答中state必須與從客戶端接收到的值保持一致。如果客戶端使用其他三種客戶端憑證類型將在此步驟直接獲得訪問令牌。OAuth2.0相比OAuth1.0做了較大簡化，比如在OAuth1.0中需要向服務接口發送由HTTP請求URL和其他參數計算而來的簽名值，而在OAuth2.0中不再計算簽名，此外，OAuth2.0也取消了oauth_timestamp和oauth_nonce兩個參數。同時，OAuth2.0對認證過程中的數據傳輸保密性提出了更高的要求，強制使用TLS來保障數據安全。

1.2獲得訪問令牌授權碼類型客戶端獲得授權許可后，需要向授權服務器發送HTTP請求以獲得訪問令牌。HTTP請求包括以下參數：grant_type、code、redirect_uri和client_id。當平臺使用授權碼許可類型時，grant_type值必須為“authorization_code”。code參數值是在授權許可步驟中從授權接口獲得的授權碼。redirect_uri和client_id與前一步驟相同。授權服務器收到HTTP請求后，需要對客戶端進行認證，并驗證授權碼合法性。如果通過授權碼合法性驗證，授權服務器需要向客戶端發送應答，頒發訪問令牌access_token和可選的刷新令牌refresh_token。此外，應答中可能還包括token_type和expires_in參數，其中token_type參數是訪問令牌類型，expires_in參數來指定訪問令牌的有效期。

1.3訪問受保護資源客戶端通過向資源服務器出示訪問令牌來訪問受保護資源，資源服務器需檢查訪問令牌，確保訪問令牌合法。如果訪問令牌合法則正常受理訪問請求，如果令牌過期，則要求客戶端重新獲取訪問令牌。如果在此之前授權服務器已經向客戶端頒發過刷新令牌，則使用刷新令牌來獲取新的訪問令牌。

2.OAuth2.0客戶端認證接口實例

本文以某社交平臺授權機制為例，分析OAuth2.0客戶端注冊和認證的流程，并以CocoaTouch為基礎實現了認證客戶端。

2.1客戶端注冊第三方開發人員在設計新的客戶端之前需要在官方網站上注冊應用，注冊信息包括應用名稱、應用平臺、應用介紹等，注冊成功之后將獲得AppKey和AppSecret，這兩個字符串分別對應client_id和client_secret參數。

2.2服務接口開放平臺提供了若干服務接口（API），與OAuth2.0認證相關的服務接口有五個，其中兩個API接口將在下文中使用到，分別是請求授權和獲取授權。請求授權用于圖1流程中第1、2步驟，地址。獲取授權用于圖1流程中第3和第4步驟，地址/oauth2/access_token。

2.3客戶端實現及安全考慮為了便于認證客戶端的實現，可以定義一個OAuth2Utility類，下面是類中幾個主要的方法。(void)authorizationRequest;//申請獲得授權(void)authorizationResponse:(NSString*)authorizationCodeclientState:(NSString*)state;//客戶端接收到授權許可(void)accessTokenRequest:(NSString*)authorizationCodegrantType:(NSString*)type;//使用授權許可申請訪問令牌(void)accessTokenResponse:(IHTTPRequest*)request;//客戶端接收到訪問令牌在移動客戶端API中，申請訪問授權需要提交的參數包括client_id、response_type和redirect_uri，如需要支持移動客戶端html5特性，需提交參數display，并將該值設置為“mobile”。所有參數需要使用x-www-form-urlencoded格式進行編碼，并通過HTTPGET/POST方式發送。比如使用授權碼類型的客戶端發送的HTTP請求可能。RFC6749規范定義的四種標準授權許可類型中，授權碼許可被廣泛支持，而在隱式許可類型中，訪問令牌作為重定向URI的一個部分直接返回給客戶端，不頒發刷新令牌。資源擁有者口令憑證許可類型和客戶端憑證許可類型由于存在巨大的安全風險，一般只在特別的場合下使用。開放平臺的請求授權服務接口將授權碼通過用戶發回給客戶端，在本例中服務接口發回客戶端的HTTP應答可以，URL中的code值就是授權碼。不少服務接口并沒有完全遵循規范的要求進行設計，比如本文的例子，容易造成很多安全隱患。Homakov［5］利用跨站請求偽造（CSRF）攻擊來非法訪問第三方資源，攻擊者可以利用這個被挾持的賬號繼續挾持其他網站的賬號［6］。此外，攻擊者還可以使用猜測授權碼、惡意客戶端授權、授權碼釣魚、用戶會話模仿等方式來獲得授權碼。搜狐微博OAuth2.0授權曾經由于設計不當，被發現在獲取授權碼的時候沒有返回state參數而造成安全隱患。為了規避安全風險，建議服務接口設計時應采納state參數，并在客戶端注冊期間使用完整的重定向URI［7］。此外，為了減少授權碼重放攻擊帶來的危害，應該盡可能縮短授權碼的有效期。客戶端獲得授權碼之后就可以向獲取授權服務接口要求交換訪問令牌，交換訪問令牌需要提交的參數包括client_id、client_secret、grant_type，如果grant_type類型為授權碼時，還必須提交code和redirect_uri參數。所有參數經過編碼之后，通過HTTPPOST方法發送到獲取授權服務接口。HTTP發送的數據可以。獲取授權服務接口對客戶端提交的參數進行驗證，如驗證通過則向客戶端發送應答，應答中包括access_token、expires_in、remind_in和uid。access_token是頒發的訪問令牌。expires_in是令牌有效期，令牌有效期取決于令牌泄漏的風險，由許多不同的因素決定。該平臺為幾種客戶端分別設置了不同的令牌有效期，比如測試客戶端的有效期為1d，普通客戶端為7d。remind_in即將廢棄，現已使用expires_in代替remind_in。uid是當前授權用戶的編號。服務接口應答數據采用JSON編碼，JSON是一種基于Javcript輕量級的數據交換格式。客戶端需要使用JSON的開發庫來幫助解讀JSON格式數據。客戶端獲得訪問令牌之后就可以使用令牌訪問資源，比如讀取公共信息或者發信息等。以讀取公共信息為例，客戶端向公共信息服務接口提交訪問令牌就能獲得最新的200條公共信息，客戶端可以通過提交參數count來設置單頁返回記錄的條數。客戶端通過HTTPGET提交數據，返回的數據使用JSON格式編碼。

2.4客戶端測試本例中客戶端應用平臺為iOS，客戶端在MacOSX10.8.3系統以及Xcode4.6.2開發環境下測試通過。圖2是客戶端運行的效果截圖。

3.結語

OAuth授權機制在許多第三方應用認證中被廣泛運用，尤其是OAuth2.0在OAuth1.0基礎上簡化了業務流程，降低了安全風險。目前很多開放平臺已經轉向OAuth2.0，并逐漸放棄對OAuth1.0的支持。OAuth協議將為多平臺之間的數據交互和認證流程簡化提供堅實的保障。

作者：吳棟淦單位：福建信息職業技術學院計算機工程系