OAuth2.0理解和用法

现在网络的资料到处都是，很容易搜索到自己想要的答案。但答案通常只能解决自己一部分的问题。如果自己想要有一套自己的解决方案，还得重新撸一遍靠谱。

我需要学下OAuth2.0吗？

没看之前以为OAuth2.0是登录认证授权的东西，自己的项目里应该是需要的。实际上OAuth是为了第三方应用访问我们资源用的，大多数开发者基本不会用到这个东西。对于自己应用的认证授权，还是基于拦截器的token，SpringSecurity即可。只有做平台级别，像微信，微博，github这种级别才会用到。而真到那个时候，再看也行，也通常不会是你来做。简而言之，非必须。

接下来，我将从几个方面了解和学习使用OAuth2.0。对不对就不管了，反正我也几乎不会用到。ps.有个项目用到了，所以才会有本文。

  1. OAuth2.0介绍和功能
  2. 微信开放平台和github的OAuth2.0接入应用
  3. 自己写一个OAuth2.0服务
  4. Springboot OAuth2.0集成

快速了解OAuth2.0

资源很多，看起来比较麻烦，可以直接看Authorization Code授权码流程，以微信登录为例子的介绍。

OAuth2.0是什么

官方介绍是： OAuth 2.0授权框架允许第三方应用程序通过协调资源所有者和HTTP服务之间的审批交互，或允许第三方应用程序自己获得访问权限，从而获得对HTTP服务的有限访问。也就是授权别人(client)访问我们的资源。

The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf.  This
specification replaces and obsoletes the OAuth 1.0 protocol described
in RFC 5849.

别人(client)是什么？

登录石墨文档可以输入账号密码登录，也可以选择微信登录，微信扫码确认后，就登录了石墨文档。石墨文档通过微信认证的方式实现了自身的认证登录。这个石墨文档就是client的角色（Role）。

什么时候需要让别人(client)访问我们的资源？

最常见的是微信授权登录，对client来说，是用户授权client拿到用户在微信上的信息，比如性别，唯一id。

我们怎么才能做到授权给别人访问我们的资源？

我们自己怎么获取自己的资源？我们登录后就可以获取到自己的账号信息等资源了。那么怎么给到别人？直接把我们的账号密码给第三者太不安全了。一个是自己的账号密码存在泄露的风险，一个是自己的账号权限太大，万一被别人删除了或者看到了不该看到的东西怎么办。在使用阿里云的时候，我们可以给自己的账号开子账号，给子账号一些权限访问哪些服务(授权太复杂了)，这样我们就可以达到最初的目的了： 让别人安全的访问我们的资源。

OAuth通过引入授权层并将client的角色与资源所有者的角色分离, 并且给client单独的凭证(access_token)，client通过access_token获取有限的资源。

OAuth2.0定义的角色

resource owner
资源的拥有者，通常就是用户，比如登录的用户。

resource server
资源服务，提供资源的服务。需要access_token才允许被调用。比如微信api，通过access_token调用它可以获取到用户的性别等信息。

client
客户端，第三方客户端，被授权访问的应用。比如石墨文档通过微信登录的时候，石墨文档就是client角色，它要用户授权获取用户微信的信息。

authorization server
资源认证授权服务。用户登录到本服务后，可以选择授权给第三方。比如微信登录，微信认证服务就是authorization server的角色。可以颁发给client code，可以通过code换取access token. 可以通过access_token认证用户。

乍一看可能有点迷乱。站在登录用户的角度，简单的分为3个阵营: 用户本身(resource owner), 用户要登录的应用(client), 用户的资源(resource server and authrization server). authorization server和resource server是一体的，一家的，比如都是微信的。这样清晰一些。只是对于微信内部，个人信息，朋友圈，公众号，小程序啥的，资源挺多，相当于多个resource server, 内部就分成了authorization server和多个resource server.

搞清楚这里面的角色后，再来看协议的流程。

OAuth2.0的协议流程

整体抽象协议流程如下。

  • A: client找用户(resource owner)请求授权，说你得让我获取你的微信昵称. 然后用户就看到微信授权页面(authorization server)显示是否允许client获取昵称。
  • B: 用户点确认，微信就会给client一个临时授权code。
  • C: client拿着上一步得到的授权code去找authorization server换一个access_token.
  • D: authorization server认证了client的参数，确认后，给client返回access_token.
  • E: client拿access_token去获取信息，比如获取用户昵称，头像。
  • F: client如愿以偿。

直接看上面的图，看到B和C都特么叫Authorization Grant, 授权发放。一会儿用户给client发放，一会儿client又找authorization发放，这是要哪样。我当年就是看了无数次这个图没看懂。接着，一般的文章又会介绍OAuth2.0的4种授权方式，结合上图的授权，就会非常容易混淆，看不懂了。

官网描述授权发放：

An authorization grant is a credential representing the resource
owner's authorization (to access its protected resources) used by the
client to obtain an access token.  This specification defines four
grant types -- authorization code, implicit, resource owner password
credentials, and client credentials -- as well as an extensibility
mechanism for defining additional types.

授权发放模式是指client获取access_token的方式。官方给了4种，

  • authorization code: 授权码
  • implicit: 隐藏式
  • resource owner password: 用户的账号密码方式
  • client: client的id认证方式
  • 当然，也可以自由扩展，能认证返回access_token就行。

grant是指授权给client，4中授权模式对应的是上图的BCD,即获取access_token的过程有4种方式。

access token存储方式？

access token就是访问资源的凭证，令牌。它的安全很重要。为了防止泄露被窃取，通常是client后端服务用token获取资源，是存储在client后台服务的，比如redis，mysql中，和用户关联存储。在浏览器上是体现不出的。那中间人就不能网络拦截到token。即access_token不应该在浏览器访问网络中出现。

以下用石墨文档(client)采用微信(authorization server & resource server)登录的方案来描述理解4种授权方式。

Authorization Code授权码

authorization code就不翻译了，代码里也是这么写的，翻译了就可能对不上了。这种方式获取token，首先用户让微信给一个code给client。client拿着code找微信换一个access_token,以后就用access_token获取用户的唯一id。

这个图对象比较多。先认识对象，微信用户(resource owner)，浏览器，石墨文档(client)，微信开放平台(authorization server)，微信api(resource server)。

首先，石墨文档(client)需要在微信开放平台(authorization)注册，获取appId和appSecret. 这组凭证是石墨自己访问微信开放平台的。access_token则是代表用户本人，注意区别。

1.微信用户通过浏览器访问了石墨文档，然后登陆页，然后点了微信登录按钮
这时候，浏览器请求石墨微信登录回调地址，石墨后台返回302，response附属location. 浏览器重定向跳转到微信二维码认证页面。

https://open.weixin.qq.com/connect/qrconnect?appid=wx5a67899f4af8b0b1&redirect_uri=https%3A%2F%2Fshimo.im%2Flizard-api%2Fauth%2Fwechat%2Flogin_callback&response_type=code&scope=snsapi_login&state=740a608f-23b4-4abd-b941-e13d2b5c0dbe#wechat_redirect

注意几个参数：

  1. appid: 石墨文档作为client在微信开发平台的凭证id
  2. redirect_uri: 认证通过后，微信开放平台添加一个code参数到这个url后面，然后浏览器重定向到这个url。这个url是石墨文档后台接收code的接口。
  3. response_type: code。固定
  4. scope: 授权范围，想获取用户哪些资料的api。网页登录为snsapi_login
  5. state: 这个是防刷的，防止csrf跨站请求伪造攻击。微信认证成功后，回调的时候会原样返回给石墨(client)。如果没这个，client接收参数就只有code，别人就是随意伪造碰撞code。而石墨生成了一次性token作为state，回调接口只有一次有效期。这里石墨用的uuid.

2.用户微信扫描二维码，通过认证
用户微信点击了确认，就代表了授权通过了，允许石墨获取access_token. 浏览器微信二维码页面收到code，拼接redirect的url，浏览器重定向到石墨后台

https://shimo.im/lizard-api/auth/wechat/login_callback?code=081r8QFa1aYaRA03J7Ha1gUXl42r8QFk&state=740a608f-23b4-4abd-b941-e13d2b5c0dbe

这个回调地址code就是微信开放平台(authorization server)颁发给石墨文档(client)的code。

石墨文档后台接收到code和state后，校验state是否有效，然后拿code和appId,appSecret去访问微信接口获取用户信息。这一步是在石墨文档后台进行的。浏览器看不到access_token. 而对于上一步生成的code，即便有人拿到code，应该已经失效了。code和state都是一次性的有效期。这样保证了access_token的安全性。

https://api.weixin.qq.com/sns/oauth2/access_token?appid=APPID&secret=SECRET&code=CODE&grant_type=authorization_code

返回：
{ 
"access_token":"ACCESS_TOKEN", 
"expires_in":7200, 
"refresh_token":"REFRESH_TOKEN",
"openid":"OPENID", 
"scope":"SCOPE",
"unionid": "o6_bmasdasdsad6_2sgVt7hMZOPfL"
}

3.石墨文档获取到用户唯一id后，根据后台用户账号的绑定关系，确认当前登录用户登录

Implicit

Implicit翻译是隐藏式，这种针对纯web前端应用，没有后台，就没办法像上面一样了，令牌只能放在前端。这种也叫client side，又称为User Agent Flow，先说具体用法。

client直接请求authorization server获取access_token. 请求参数是client id和redirect url, 最后认证返回后拼接#access_code. 类似下图。

由于access_token网络传输，并不安全，很少使用这种方案。qq互联提供了一种，见 https://wiki.connect.qq.com/%e4%bd%bf%e7%94%a8implicit_grant%e6%96%b9%e5%bc%8f%e8%8e%b7%e5%8f%96access_token

1.请求认证的url参数： clientId, redirectUrI, Scope,state

  • client_id: 注册应用的 id，比如石墨文档在qq注册应用的appid
  • redirect_uri: 认证成功后要回调的地址，这个要和注册的时候一致
  • response_type: token
  • state: 同样的一次性随机数，会原样返回给client，防止csrf攻击。

2.认证成功后，回调地址中的access_token
qq认证成功后的示例：

http://graph.qq.com/demo/index.jsp?#access_token=FE04************************CCE2&expires_in=7776000&state=test

可以看到参数access_token是通过#传递的。这里涉及一个叫中间人攻击的安全问题，见http://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html。

注意，令牌access_token的位置是 URL 锚点（fragment），而不是查询字符串（querystring），这是因为 OAuth 2.0 允许跳转网址是 HTTP 协议，因此存在"中间人攻击"的风险，而浏览器跳转时，锚点不会发到服务器，就减少了泄漏令牌的风险

qq提示
可通过js方法：window.location.hash来获取URL中#后的参数值。

password

password需要用户把微信账号和密码给石墨文档，石墨拿着去微信换token，这种放弃看了，不可能给的，微信也不支持。

client

这种就是纯后台方案。client拿着client_id和secret去换access_token。通常就是我们后台服务调用的时候用到。比如使用aws的s3或者阿里云的oss上传文件。我们需要通过ak，sk认证，获取一个token，拿token去上传文件。这个流程写起来还挺麻烦的，一般都会封装好客户端给我们用。这里就不涉及用户了，只是客户端自己的认证了。

customize
自定义，我们也可以username + password登录走OAuth2.0校验。只是没client，或者说每个登录用户类似client。登录后返回access_token, 用户可以访问其他资源。

更新令牌

前面讲的4个授权方式，都是为了获取access_token。返回格式类似微信的：

{ 
"access_token":"ACCESS_TOKEN", 
"expires_in":7200, 
"refresh_token":"REFRESH_TOKEN",
"openid":"OPENID", 
"scope":"SCOPE",
"unionid": "o6_bmasdasdsad6_2sgVt7hMZOPfL"
}

openid,unionid并不是必须的，这是微信认证用户的唯一的id。在微信的设计中，

  • access_token: 接口调用凭证，用来获取资源信息，比如用户的头像，昵称等。超时时间很短。微信设定为2h。
  • expire_in: access_token的超时时间，单位秒
  • refresh_token: 用户刷新access_token用的token。超时时间比较久。微信设定超时为30天，失效后需要用户重新授权。
https://api.weixin.qq.com/sns/oauth2/refresh_token?appid=APPID&grant_type=refresh_token&refresh_token=REFRESH_TOKEN
返回
{ 
"access_token":"ACCESS_TOKEN", 
"expires_in":7200, 
"refresh_token":"REFRESH_TOKEN", 
"openid":"OPENID", 
"scope":"SCOPE" 
}

请求刷新token：

  • appid: client id,石墨注册在微信平台的id
  • grant_type: refresh_token固定
  • refresh_token: 上一步获取到的token

未完待续...

参考

posted @ 2021-04-15 23:34  Ryan.Miao  阅读(9271)  评论(4)  编辑  收藏  举报