OAuth

OAuth授权流程
　　OAuth2是从OAuth发展而来的，虽然不向下兼容，但了解OAuth能更好的理解OAuth2的一些改变。
OAuth里存在三个主要角色：用户、服务提供方和服务消费方。不少文档会把服务消费方说成是客户端，对于SP来说，这个说法没什么问题，但我感觉这个说放容易引起混淆，所以我这里还是用服务消费方来描述。按流行的口号，服务提供方一般对外宣称自己是某某某开放平台，而服务消费方则是各种第三方应用。用户在平台上有一些已有资源，如好友关系，照片等。

　　几乎所有的OAuth平台都有类似的背景：他们原先积累了一大堆的真实用户，在互联网开放的趋势下，主动或被动的需要支持第三方应用的接入。第三方应用为了使其功能更加丰富完整，希望从平台能获取甚至操作当前用户的资源。用户很可能不希望第三方得知他原有的帐号和密码，原因很明显，安全考虑嘛。服务提供方也不希望第三方直接使用用户的帐号和密码登录平台操作用户数据，为啥？不便于数据统计和维护嘛，希望对 哪个第三方操作哪个用户数据 和 哪个用户操作自己的数据 两种处理流程有所区别。第三方很无辜，经常大喊“我觉不会使用任何途径存储用户的帐号！”。即使真有人相信这些誓言，但也很难确保第三方使用帐号敏感数据时，不被第四方所捕获，所以，认真你就输了。

　　为了解决上面的问题，准确的说是让三种角色互相信任，OAuth由此而生。在没有第三方的情况下，服务提供方和用户可以认为是互相信任的，因为用户用域名来确保自己访问的是一个受信的站点；服务提供方则要求用户登录，并且登录会话可以控制。

　　应为第三方一般是不知名的，用户很难区分第三方合不合法，所以用户需要通过服务提供方来证实第三方，例如位于服务提供方的OAuth授权页面会简单的介绍该应用的简单介绍，正是这些介绍使得用户可以相信，该应用是一个合法登记的第三方。

　　为了让服务提供方信任第三方应用，第三方应用在必要时需要向服务提供方提供身份凭据。最简单的办法就是第三方开发者去服务提供方那去注册个帐号，然后在需要时用这个帐号来证明自己的身份。这种第三方应用的帐号，下面统称应用帐号。由于第三方的请求不会有人工的干预，所以应用帐号的帐号密码一般由服务提供商提供，方便服务提供方管理，安全系数也较高，因为服务提供方可以制定规则，使密码更难以伪造或猜测。

　　按理说，第三方应用除了到SP处申请一个应用帐号外，也有其他办法证实自己的身份。

　　例如可以使用HTTPS连接，让“第四方”去证明。OAuth2使用的就是HTTPS连接，但也仅仅是服务端认证，客户端并不做保证。估计一个方面的原因是，应用的数量很多，一般都是中小规模开发商开发的，客户端也要认证的话，证书申请门槛较高，一个账号密码可以解决的问题有必要去申请证书吗？另一方面是，很多应用是没有服务端的，使用双向HTTPS认证无疑将这些应用拒之门外。

　　上面的方法是，用户通过服务提供方，去识别第三方是否合法。还有种方式是：服务提供方通过用户，去识别第三方是否合法。但OAuth里没有这种方式的体现，但OAuth2里有类似的方式，那就是提供用户的帐号密码换取AccessToken，名字应该叫“资源所有者密码凭据”。如果第三方应用只是开发者自娱自乐的小应用，这种方式是最简单的。

　　经过上面的注册和授权流程，用户和服务提供方都可以确认第三方应用的身份了，那第三方如何确认服务提供方和用户的身份？

　　第三方应用怎么确认服务提供方的身份呢？很简单，域名就是服务提供方的唯一标识，只要DNS不被劫持的话。第三方应用根据服务提供方的返回内容确认用户身份，载体是操作令牌AccessToken，为了方便后面统称ATOK，在OAuth里，ATOK的有效期是从用户授权成功，到用户取消授权，对第三方来说，几乎是永久的。至于用户授权之后取消授权，再授权的时候，两次ATOK是否一样，第三方能否处理好这种情况，OAuth里没有提及，看实现者的心情了。

　　把上面所说的综合在一起，可以得到一个OAuth的雏形版本：

　　　四个步骤
　　OAuth授权分四步。

　　第一步，应用向服务提供方申请请求令牌(Request Token)，服务提供方验证通过后将令牌返回。这个步骤由于涉及到应用帐号密码，在应用的服务端发起，所以这个步骤对用户透明。

　　第二步，应用使用请求令牌让浏览器重定向到服务提供方进行登录验证和授权。服务提供方校验请求令牌，将第三方的资料显示给用户，提示用户选择同意或拒绝此次授权。如果用户同意授权，发放已授权令牌并将用户引导到当前应用的注册地址。这个步骤从重定向开始到引导回注册地址之前，应用方并不参与用户身份校验和授权过程，确保第三方不可获得用户的真实帐号密码。

　　第三步，用已授权令牌向服务提供方换取ATOK。第三方应用需在服务端发起请求，用帐号密码和上一步的令牌换取ATOK，这个步骤对用户而言也是透明的。如果前两步分别是让服务提供方认证应用和用户，那这步就是用户和服务提供方再次认证第三方应用。因为用户浏览器将第二步的结果重定向到第三步，除非用户DNS被劫持，否则就能确保重定向到的是合法的地址。曾经我很困惑在用户授权之后为何不直接返回ATOK而需要再次换取，估计是出于对ATOK的安全考虑，用户浏览器一端存在太多的可能性让ATOK泄漏，最安全的办法还是让第三方服务端来获取和保管ATOK。

　　第四步，用ATOK作为令牌访问受保护资源。很多时候，权限是有多种类别的。ATOK包含了某个用户对某个应用的授权凭据，准确的说，ATOK对应用户授权时所赋予的一系列权限的集合。所以在这一步，除了校验ATOK的合法性之外，服务提供方还需对该ATOK是否拥有足够的权限执行被保护操作进行判断。

　　单次签名
　　在OAuth里，OAuth的相关请求都要做单次签名，目的是防止OAuth的请求被篡改和重放。签名当然是拿应用帐号的密码来做签名，其实就是对HTTP请求中所有OAuth相关的参数都连在一块，使用密码计算某种哈希值作为签名。OAuth规范里描述了签名的规则，那是相当的繁琐、复杂，足以吓跑一大堆未经世事的开发者。随便找一个OAuth开放平台的API文档，我相信在OAuth授权流程有接近一半会在描述怎么产生签名构造一个合法的HTTP请求。有一对文字图片描述还不够，各开放平台几乎无一例外地提供各种开发语言下的SDK，为求尽量降低技术门槛。即使如此，不少开发者依然觉得，OAuth的签名过程实在是太复杂了，而这些复杂也没有带来预期的好处。

　　重定向地址
　　为了防止有攻击者伪造重定向地址骗取用户授权，服务提供方应对授权时的重定向地址进行验证。所以注册时，第三方应提供重定向地址。服务提供方可以直接对重定向地址进行等值判断，但这样的话就没办法让第三方在授权过程中传递状态，只能借助Cookie/Session之类的方式了。服务提供方也可以判断重定向地址是否同一个域，这样的话应用方就可以在URI里传递少量状态。对于一些没有服务端的第三方Web应用，由于代码是公开的，将应用的帐号密码存在页面里并不合适。OAuth则建议不使用重定向地址，让用户在授权后，把授权码人工输入到应用中进行下一步。记得有段时间FaWave也是这么添加新帐号的。