前言
最近在尝试调用strava api接口，希望获取存储在上面的数据。然而登录服务器第一步就是要通过OAuth2.0的认证，因此本篇主要记录了我对于OAuth的学习和认识，以及使用java的实践。
OAuth认证介绍
OAuth是一种开放的标准协议，他允许第三方应用向资源拥有者发起请求并获取资源的访问权限，而不需要向第三方应用暴露用户的密码，被广泛用在第三方登录场景中。OAuth1.0于2007年首次被提出，由于存在着伊西俄安全性问题，目前绝大部分互联网公司采用改进后的OAuth2.0作为认证协议。本文将先简单介绍一下OAuth1.0的流程并说明其缺陷，进而详细介绍OAuth2.0以及他的实践。
OAuth1.0
OAuth1.0的认证流程如下图所示：
流程中主要涉及到三个角色
consumer：需要通过OAuth协议请求服务提供方获得数据的第三方应用。
service provider：服务提供方，允许第三方应用通过OAuth协议获取相关数据。
User：用户，在服务提供方service provider存储数据的人。
流程：
- consumer向服务提供方发起申请，获得Request token。
- 服务提供方返回consumer未授权的Request token以及secrete。
- consumer携带者request token和secrete请求服务器，调起授权页面。
- 用户授权
- 服务提供方将用户重定向到consumer中，并返回了授权后的request token。
- consumer使用授权后的request token交换到了access token。
- consumer采用access token获取服务提供方存储的用户数据。
sequenceDiagram
consumer->> service provider: 请求未授权的request token
service provider -->> consumer: 返回未授权的request token和token secrete
consumer ->> service provider: 携带上未授权的request token和callback请求服务器
service provider ->> service provider: 用户授权登录
service provider -->> consumer: 服务器重定向用户到consumer，并返回授权后的request token
consumer -> service provider: 携带授权后的request token，请求换取access token
service provider --> consumer: 返回access token及access token secrete
OAuth1.0优点在于会对每个token进行加密 缺点：
- 采用http协议
- 易受到劫持： 攻击者会首先接入consumer，并向service provider请求，获得一个没有授权的request token。此时，原本应该将攻击者重定向到service provider进行授权登录，但是这一步被攻击者截断，攻击者同时也通过一定的方式获得重定向的url。攻击者通过某种方式让用户点击这个url，用户登录授权页面登录后，攻击者伪造回调地址，并换取用户的access token，从而访问到用户的个人数据。
根本问题在于，请求未授权request token、授权登录、获取access token过程中，service provider无法判断这些请求是否是同一个用户发起，进而产生了漏洞。
OAuth2.0
Oauth2.0于2012年发布，解决了1.0中参数众多、实现复杂以及易被劫持的问题。目前是被大部分开放平台组为的认证协议。
Oauth2.0包含以下几个角色定义：
resource owner：提供用户资源服务的平台。
resource server：资源服务器
client：客户端
authorization server：授权服务器，负责访问令牌、验证令牌以及刷新令牌的颁发
Oauth2.0协议中有多种授权模式：授权码模式、简化模式、密码模式、客户端模式。在授权码模式中，用户会在授权服务器上授权，返回给客户端授权码code，客户端通过code交换得到access token以及refresh token，access token有着一定的过期时间，为了防止用户多次授权，可采用refresh token刷新access token。客户端可使用access token访问用户的资源数据。
第三方登录流程：
- 第三方应用引导用户到授权服务器上授权
- 用户完成授权后，客户端会得到对应的授权码code
- 客户端携带code继续请求授权服务器，请求授权
- 服务器验证code通过后，返回客户端对应的access token、refresh token、expire at等信息
- 客户端通过access token访问用户数据
Q：授权过程中为什么先要code，在请求到access token呢？为什么不合并成一次请求？ A：如果第三方应用采用http协议请求access token，过程中可能会被挟持，直接得到access token会泄露用户全部数据。code一般性只有较短的有效时间，而且连续使用两次会直接让access token失效，这个好处在于，如果授权的过程中code被劫持了，当第三方应用也得到code时，连续请求会让劫持得到的access token失效，保证了安全性。
OAuth2.0的实践
-
输入一个授权请求，请求中带上客户端id、响应形式、重定向地址以及授权的范围。用户会被引导至授权登录页面，点击授权后会进行重定向。
-
点击授权，用户会被重定向到redirect url上，url后会带上一个授权码code
- 最后将授权码code携带上，再次请求授权服务器，就可以得到获取用户数据的专属access token和刷新access token的refresh token，以及token的过期时间啦！
