谈谈基于OAuth 2.0的第三方认证 [中篇]

虽然我们在《上篇》分别讨论了4种预定义的Authorization Grant类型以及它们各自的适用场景的获取Access Token的方式，我想很多之前没有接触过OAuth 2.0的读者朋友们依然会有“不值所云” 之感，所以在介绍的内容中，我们将采用实例演示的方式对Implicit和Authorization Code这两种常用的Authorization Grant作深入介绍。本章着重介绍Implicit Authorization Grant。

Implicit Authorization Grant授权流程

假设我们的客户端应用集成了Windows Live Connect API认证服务，并且在成功取得用户授权并得到Access Token之后调用相应的Web API获取当前登录用户的个人信息。一般来说，Implicit类型的Authorization Grant大都被将浏览器作为执行上下文的客户端应用采用，换句话说，这样的客户端就是在浏览器中执行的JavaScript程序。下图体现了这样一个采用Implicit类型的Authorization Grant的客户端应用取得授权、得到Access Token并最终获取到受保护资源（登录用户个人信息）的完整流程。

在具体介绍认证实现原理之前，我们不妨先来演示一下最终达到的效果。我们在ASP.NET Web API应用中定义了如下一个继承自ApiController的DemoController，它具有唯一一个用于获取当前登录用户个人基本信息的Action方法GetProfile。在该方法中，它通过我们定义的扩展方法TryGetAccessToken从当前请求中提取Access Token，然后利用它调用Windows Live Connect提供的Web API（https://apis.live.net/v5.0/me）。

)] 

class DemoController : ApiController

   3: {

public HttpResponseMessage GetProfile()

   5:     {

string accessToken;

out accessToken))

   8:         {

new HttpClient())

  10:             {

, accessToken);

return client.GetAsync(address).Result;

  13:             }

  14:         }

 };

  16:     }

  17: }

集成Windows Live Connect认证的实现最终是通过应用在DemoController类型上的AuthenticateAttribute特性来完成的，这是一个AuthenticationFilter，作为参数的URL指向一个用于获取和转发Access Token的Web页面。现在我们直接利用浏览器来调用定义在DemoController中的Action方法GetProfile，如果当前用户尚未登录到Windows Live，浏览器会自动重定向到Windows Live的登录界面。当我们输入正确Windows Live帐号和密码后，当前用户的基本信息以JSON格式显示在浏览器上（如果尚未对该应用进行授权，如上图所示的页面会呈现出来），具体的效果如下图所示。

应用在DemoController上的AuthenticateAttribute特性完成了针对授权页面的重定向和Access Token的请求和接收。除此之外，为了让浏览器能够在第一次认证之后能够自动地发送Access Token，我们利用AuthenticateAttribute将Access Token写入了Cookie之中，这与Forms认证比较类似。不过就安全的角度来讲，利用Cookie携带安全令牌会引起一种被称为“跨站请求伪造（CSRF：Cross-Site Request Forgery）”的安全问题，所以通过HTTP报头来作为安全令牌的载体是更安全的做法。

如下所示的代码片断体现了整个AuthenticateAttribute特性的定义，我们可以看到它同时实现了IAuthenticationFilter和IActionFilter。字符串常量CookieName表示携带Access Token的Cookie名称，只读属性CaptureTokenUri表示授权服务器发送Access Token采用的重定向地址，它指向一个我们由我们设计的Web页面，该页面在接受到Access Token之后会自动向目标资源所在的地址发送一个请求，该请求地址以查询字符串的形式携带此Access Token。（之所以我们需要利用一个Web页面在客户端（浏览器）接收并重发Access Token，是因为授权服务器将返回的Access Token至于重定向URI的Hash（#）部分，所以在服务端是获取不到的，只能在客户端来收集。这个Web页面的目的在在于在客户端获取的Access Token并发送到服务端。）

   1: [AttributeUsage(AttributeTargets.Class| AttributeTargets.Method)]

class AuthenticateAttribute : FilterAttribute, IAuthenticationFilter, IActionFilter

   3: {

;

private set; }

   6:  

string captureTokenUri)

   8:     {

this.CaptureTokenUri = captureTokenUri;

  10:     }

  11:  

public Task AuthenticateAsync(HttpAuthenticationContext context, CancellationToken cancellationToken)

  13:     {

null);

  15:     }

  16:  

public Task ChallengeAsync(HttpAuthenticationChallengeContext context, CancellationToken cancellationToken)

  18:     {

string accessToken;

out accessToken))

  21:         {

;

this.CaptureTokenUri, context.Request.RequestUri);

;

  25:  

;

;

;

  29:             uri = String.Format(uri, redirectUri, clientId, scope);

new Uri(uri), context.Request);

  31:         }

null);

  33:     }

  34:  

public Task<HttpResponseMessage> ExecuteActionFilterAsync(HttpActionContext actionContext, CancellationToken cancellationToken, Func<Task<HttpResponseMessage>> continuation)

  36:     {

  37:         HttpResponseMessage response = continuation().Result;

string accessToken;

out accessToken))

  40:         {

  41:             response.SetAccessToken(actionContext.Request, accessToken);

  42:         }

return Task.FromResult<HttpResponseMessage>(response);

  44:     }

  45: }

在实现的ChallengeAsync方法（该方法在认证过程中向客户端发送“质询”响应）中，我们利用自定义的扩展方法TryGetAccessToken试着从当前请求中获取携带的Access Token。如果这样的Access Token不存在，我们通过为HttpAuthenticationChallengeContext的Result属性设置一个RedirectResult对象实现针对Windows Live Connect授权页面的重定向，相关的参数（respone-type、redirect_uri、client_id和scope）以查询字符串的形式提供。

值得一提的作为重定向地址的参数redirect_uri，我们会将当前请求的地址作为查询字符串（名称为“requestUri”）附加到CaptureTokenUri上得到的URI作为该参数的值，当前请求的地址正式Web页面发送Access Token的目标地址。

另一个实现的ExecuteActionFilterAsync方法复杂将Access Token写入响应Cookie之中，具体的操作实现在我们自定义的扩展方法SetAccessToken中。下面的代码片断给出了两个扩展方法SetAccessToken和TryGetAccessToken的定义。

class Extensions

   2: {

string accessToken)

   4:     {

//从Cookie中获取Access Token

null;

   7:         CookieHeaderValue cookieValue = request.Headers.GetCookies(AuthenticateAttribute.CookieName).FirstOrDefault();

null != cookieValue)

   9:         {

  10:             accessToken = cookieValue.Cookies.FirstOrDefault().Value;

true;

  12:         }

  13:         

//从查询字符串中获取Access Token

];

string.IsNullOrEmpty(accessToken);

  17:     }

  18:  

string accessToken)

  20:     {

if (request.Headers.GetCookies(AuthenticateAttribute.CookieName).Any())

  22:         {

return;

  24:         }

new CookieHeaderValue(AuthenticateAttribute.CookieName, accessToken)

  26:         {

true,

  29:         };

new CookieHeaderValue[] { cookie });

  31:     }

  32: }

在我们演示的实例中，应用在DemoController类型上的AuthenticateAttribute特性的CaptureTokenUri属性（“https://www.artech.com/webapi/account/capturetoken”）指向定义在AccountController这么一个Controller（ASP.NET MVC的Controller，不是ASP.NET Web API的HttpController）的Action方法CaptureToken，具体定义如下所示。

class AccountController : Controller

   2: {

string requestUri)

   4:     {

   5:         ViewBag.RequestUri = requestUri;

return View();

   7:     }

   8: }

由于AuthenticateAttribute在调用Windows Live Connect的API获取Access Token所指定的重定向地址具有一个名为“requestUri”的查询字符串，其值正好是调用Web API的地址，该地址会自动绑定到Action方法CaptureToken的requestUri参数上。如果上面的代码片断所示，该方法会将该地址以ViewBag的形式传递到呈现的View之中。

   1: <html>

   2:     <head>

></script>

>

   5:             $(document).ready(function () {

'@ViewBag.RequestUri';

'?') >= 0) {

 + location.hash.slice(1)

   9:                 }

else {

 + location.hash.slice(1)

  12:                 }

  13:                 location.href = redirectUri;

  14:             });

  15:         </script>

  16:     </head>

  17: </html>

上面的代码片断代表Action方法CaptureToken对应View的定义。在该View中，我们从当前地址的Hash（#）部分得到Access Token，并将其作为查询字符串附加到从ViewBag中得到的资源访问地址上，并通过设置location的href属性的方式携带Access Token对Web API再次发起调用。

谈谈基于OAuth 2.0的第三方认证 [上篇]
谈谈基于OAuth 2.0的第三方认证 [中篇]
谈谈基于OAuth 2.0的第三方认证 [下篇]