理解oauth

oauth 的诞生为了解决什么问题？

1，为了自己的用户不流失，在安全的情况下接入第三方服务。

2，为了解决第三方服务使用服务商资源的时候保证尽可能安全。

oauth的角色及其关系

oauth中有3个角色，用户，服务商，第三方服务。用户于服务商之间存在完全信任关系，用户把所有信息都放在服务商那里。第三方服务给用户提供服务需要用户的一些信息。

oauth本质

oauth的策略本质即是为第三方服务下发用户令牌，第三方服务通过令牌可以拿到用户的部分可读信息。由此可以将服务商的身份用在多个网站处。对这个本质提出几个问题：

1，令牌是什么？令牌是一个身份的象征，古时候，皇帝亮出自己的令牌，小老百姓就纷纷下跪，不然就要杀头，不光皇帝，其他任何人拿着皇帝的令牌亮出都一样。皇帝只有一个，这个令牌标识了皇帝，必须是唯一的。那么oauth中令牌也需要符合上述条件，唯一性。由此想到uuid等唯一的标识。可以作为唯一标识下发给第三方，第三方拿到了标识以后，就可以用标识来服务商这里取数据了。

2，为什么要下发一个令牌，用户换取用户身份？首先，用户对第三方服务不完全信任，不希望自己的账户密码被第三方服务知道。当然如果希望，服务商也不提供这样的服务，因为服务商承诺用户的账户密码不可能给别人，如果给了，服务商来一个服务你给别人账户密码，生意还做不做。万一第三方服务泄露，你也就泄露了。因此就算用户鼓励服务商提供账户密码，服务商也不能。因此下发令牌就是oauth的原则。

oauth流程

基于本质设计基本流程：用户访问第三服务时，第三方服务需要身份，就去服务商那里取身份，服务商下发一个令牌给第三方。

问题1，下发谁的令牌？类似我们登录王者荣耀时，王者荣耀要拿身份直接把微信拉起来，进入微信点击。同时也可以跳到qq登录页输入账户密码或者直接选择已经在线的账户登录。也就是在第三放去服务商那里的时候，第三方服务是需要知道是要谁的身份，那么这个时候需要用户点击或者输入用户名密码，这个动作输入用户名密码不是第三方服务的，而是服务商的页面，也就是登录服务商。(手机上微信处于登录状态，那么直接把手机上的身份发给服务端，服务端就直接下发令牌给第三方即可。)

为解决上述问题，流程需要添加用户确认身份动作：用户访问第三服务时，第三方服务需要身份，就去服务商那里取身份，服务商确认用户身份，然后下发一个令牌给第三方。

问题2，令牌下发给第三方，那么第三方如果令牌泄漏了，那么任何人都可以拿着令牌来取用户的身份，虽然没有账号密码权限大，但是令牌可访问的数据也就泄露了。因此对令牌需要设计一个过期时间，令牌过期以后就不可用了，重新下发。过期时间多长呢？据说一线大厂都是2小时。(具体看场景吧)但是在这2个小时内，同样泄露了有着严重的后果。因此对此，需要第三方也要在服务商里面获取一个账户密码，由此来确认第三方服务的身份，那么第三方服务在服务商中就表现为一个应用。如果没有用户身份，只拿个令牌，也不认。

上述过程通过设置应用的身份和用户的身份来限制，但是如果两个数据泄露仍然存在安全的问题。进行以下分析

1，首先我们考虑第三方数据库泄露，因此我们设置令牌有效期为2小时，按理这种事发生概率很小。因为注册的第三方应用也需要被服务商授权，具备一定的信任。

2，网络传输中的令牌泄露。网络传输仅仅在于客户端到服务端网络传输中存在网络安全问题。以上oauth流程中，服务商向用户确认身份后，服务商即可发送令牌给第三方。如果直接发送给第三方服务端，服务端到服务端基本不存在安全问题。但是这个时候用户客户端还停留在服务商的登录成功页面，如果给出重定向往回跳转，客户端也不具备标识知道这是哪个客户端登录的，为了解决这个问题，这个令牌需要下发客户端重定向访问第三方应用服务端的时候标识人的身份。

至此，oauth1.0的基本雏形出现了，oauth1.0的实现方案即与以上推导结果一致。

oauth1.0流程

1，第三方请求request token， 作为第三方应用的身份标识。

2，带着request token向服务商请求用户身份，服务商确认用户。

3，用户确认完毕带着用户token（令牌）重定向到callback地址，这个callback是第三方提供的一个服务。

oauth1.0中对callbackurl没有强制要求，如果不填则返回一个静态页面，用户去复制这个access token请求服务端。就有人说了用户自己复制，这不是闹着玩吗？可是我印象里在念书那会手机端上有自动复制粘贴验证码帮助自动登录的功能。

接下来说oauth1.0存在的安全问题：

1，攻击者可以把callback写成自己的，然后请求过去诱导用户授权，用户一旦授权，攻击者就可以拿着令牌去请求用户身份了。

2，如果说不适用callbackurl方式，oauth1.0支持这种给一个静态地址里面写入令牌，只要抢在用户授权后访问前去访问这个网址就能拿到用户令牌。

我觉得其实只要在服务商处对callback进行一个校验，也就是限定域名，那就不会存在第一种安全问题了。但为解决安全问题，oauth提出oauth1.0a做出修补。

oauth1.0a对oauth1.0的改进

在oauth1.0的基础上作出了改进:

1，oauth1.0a中在请求request token时就需要填入callbackurl，这里的signature是加入了callbackurl的签名，这样攻击者没办法猜到加入callbackurl以后的签名的，因此oauth1.0用户没法使用自己的callbackurl的。

2，oauth1.0a 不支持静态页面授权。通过callbackurl拿到的也不再是一个令牌，而是一个授权码，用这个授权码再去获取用户身份令牌。也就是这个令牌已经不被客户端知道了。有服务的去获取与使用，唯一标识当前操作用户的身份。

综合以上的情况，终于是实现了安全的开放授权协议。
为什么说他是安全的了呢？
访问应用的用户的所有信息与服务商之间的交互，都有了权限校验，其他方没在服务商中注册过合法的信息，是无法从服务商出获取到任何数据，因此，服务商开放的信息一定是被服务商信任的应用处。

oauth 2.0

由于oauth 1.0 的支持比较单一，仅仅能用于web应用，且其授权过程较为复杂。针对此类问题，oauth2.0去掉了其中复杂的签名()部分，并且提供了4中授权流程，不再只支持单一的授权。

为满足各中需求，针对有服务端的第三方服务，提供的是：Authorization Code，这种方法最贴近oauth1.0a，采用授权码来获取access token。即适用于web应用的开放授权。

1，第三方请求服务商，需要指定response_type 为code，即返回一个授权码

2，服务商得到user的同意，把code 打给redirect_uri

3，第三方拿到授权码，服务端拿着自己已知的sercet 和 code 去获取令牌。这里返回两个令牌，一个短期有效，另一个长期有效，可以多次通过长期token获取短期token。

这里针对没有服务端的第三方服务（也可以叫第三方应用），他就把服务商当着服务端，但是服务端需要确认他的身份，就必须走个授权，这种方式叫：Implicit Grant(这种方式非常危险，token应该只在会话期内有效)

1，第三方应用请求服务端，指定response_type 为 token，那么就不返回授权码，而是返回一个token。

2，服务商得到用户的同意以后，把token打给客户端。

3，这个token通过redirect_uri 打到客户端，客户端拿到以后token即可使用。

针对可信的应用，拿着用户的用户名密码来请求资源，oauth2.0也提供这样的服务：Resource Owner Password Credentials。

1，第三方服务带着用户名和密码来服务端请求grant_type = password，返回要给token给他就完事了。

还有最后一种，只是带着应用身份哪一个应用身份的凭证来，不验证用户身份的方式。叫做：Client Credentials。

1，带着应用的id和sercet来请求access token，返回一个给他就完了。

这样拿到的token只能访问与用户无关的数据，或者进行与用户无关的操作。

总结一下：oauth 2.0 的 4种模式，安全的级别不一样，一方面对应用的信任程度与及对应用类型均做出相应的妥协。

讨论 _{(这部分随时添加)}

1，refresh token的作用，oauth官方文档说，refresh token的获取只与授权服务器交互，通过refresh可以获取access token，引入refresh token的好处有两个，一个是access token可能会被存在端上，同时会频繁的与资源服务器之间交互，容易被泄露出去。因此access token有过期时间，比较短，保证安全。access token过期，就使用refresh token去刷新，这个refresh token放在服务端，只与授权服务器之间交互，所以可以设置较长时间，access token与资源服务器交互，可以获取资源，过期时间较短。

---

侵删，参考
https://blog.huoding.com/2011/11/08/126