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

1.oauth2.0協(xié)議流程

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

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

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

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

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

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

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

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

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

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

3.結(jié)語

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

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