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协议将为多平台之间的数据交互和认证流程简化提供坚实的保障。

作者：吴栋淦单位：福建信息职业技术学院计算机工程系