OAuth2介绍 | TBH个人博客

重点介绍授权码模式，以及实现第三方QQ登录并获取信息

OAuth介绍

OAuth（开放授权）是一个开放标准，允许用户授权第三方移动应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方移动应用或分享他们数据的所有内容

OAuth2.0是OAuth协议的延续版本，但不向后兼容OAuth 1.0即完全废止了OAuth1.0

OAuth2包括：

授权码模式（authorization code）
简化模式（implicit）
密码模式（resource owner password credentials）
客户端模式（client credentials）

具体可以参考：理解OAuth 2.0

授权码模式过程

我们先用QQ来理解一下，假如我现在做了个网站，想要实现QQ登录，这里分为：QQ认证服务器，QQ资源服务器(有权限时访问会获取该QQ账户的信息，如头像)，客户端(这里指我的网站)，服务端(我个人的网站服务端)

@startuml
'https://plantuml.com/zh-dark/sequence-diagram
'客户端 认证服务器 资源服务器 服务端

'获取code
'客户端 -> 服务端:选择QQ登录\n「可省略，由客户端直接请求认证服务器」
'服务端 -> 客户端:302重定向至认证服务器，携带response_type、client_id、redirect_uri、state等，见下文\n「可省略，由客户端直接请求认证服务器」
客户端 -> 认证服务器:携带response_type、client_id、redirect_uri、state等
认证服务器 -> 客户端:302重定向至redirect_uri，携带code

'获取access_token
客户端 -> 服务端:(redirect_uri对应地址)携带code
服务端 -> 认证服务器:携带grant_type、client_id、*client_secret*等，见下文\n根据code换access_token
认证服务器 -> 服务端:返回access_token、expires_in、refresh_token

'获取资源
服务端 -> 资源服务器:携带access_token，获取账户资源，如QQ头像、昵称
资源服务器 -> 服务端:返回对应资源
服务端 -> 客户端:返回对应资源
@enduml

关于客户端->认证服务器和服务端->认证服务器可参考QQ给出的文档：使用Authorization_Code获取Access_Token

获取Authorization Code：

参数	是否必须	含义
response_type	必须	授权类型，此值固定为“code”。
client_id	必须	申请QQ登录成功后，分配给应用的appid。
redirect_uri	必须	成功授权后的回调地址，必须是注册appid时填写的主域名下的地址，建议设置为网站首页或网站的用户中心。注意需要将url进行URLEncode。
state	必须	client端的状态值。用于第三方应用防止CSRF攻击，成功授权后回调时会原样带回。请务必严格按照流程检查用户与state参数状态的绑定。
scope	可选	请求用户授权时向用户显示的可进行授权的列表。可填写的值是API文档中列出的接口，如果要填写多个接口名称，请用逗号隔开。例如：scope=get_user_info,list_album,upload_pic 不传则默认请求对接口get_user_info进行授权。建议控制授权项的数量，只传入必要的接口名称，因为授权项越多，用户越可能拒绝进行任何授权。
display	可选	仅PC网站接入时使用。用于展示的样式。不传则默认展示为PC下的样式。如果传入“mobile”，则展示为mobile端下的样式。

通过Authorization Code获取Access Token：

参数	是否必须	含义
grant_type	必须	授权类型，在本步骤中，此值为“authorization_code”。
client_id	必须	申请QQ登录成功后，分配给网站的appid。
client_secret	必须	申请QQ登录成功后，分配给网站的appkey。
code	必须	上一步返回的authorization code。如果用户成功登录并授权，则会跳转到指定的回调地址，并在URL中带上Authorization Code。例如，回调地址为`www.qq.com/my.php` ，则跳转到：`http://www.qq.com/my.php?code=520DD95263C1CFEA087******` 注意此code会在10分钟内过期。
redirect_uri	必须	与上面一步中传入的redirect_uri保持一致。
fmt	可选	因历史原因，默认是x-www-form-urlencoded格式，如果填写json，则返回json格式
need_openid	可选	need_openid=1，表示同时获取openid。

当然，我们需要去标识该用户，可以通过携带AccessToken，请求OpenID接口，即可获取对应用户身份标识OpenID。

和简化模式相比，多了通过code换取AccessToken的过程，这个过程是在自己的后台服务器完成的，secret保存在服务端，不会暴露给用户，从而保证更高的安全性

即：授权码模式（authorization code）是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器，与”服务提供商”的认证服务器进行互动

Q1: code换取token时，为什么也要携带redirect_uri？

核对授权码和重定向URI, 验证是否对应。
(网上有说是回调地址，之后要回调之类的。这个步骤发生在获取code之后，认证服务器返回302重定向到redirect_uri，在根据code获取token时，很明显跟这个原因没关系)

Q2: 在获取code时，redirect_uri为什么有些授权方认证时是可选的？

RFC6749 3.1.2. Redirection Endpoint里写了，这个redirect_uri可以通过请求参数传给认证服务器，也可以在客户端在认证服务器注册的时候提前设置

Q3: 为什么需要有code这一步，直接拿到token不行吗？

说法一：Why is there an “Authorization Code” flow in OAuth2 when “Implicit” flow works so well?

说法二：secret存储在客户端是不安全的，中间加一层服务端，把需要secret获取token的交由服务端-认证服务器处理，不暴露给外界，保证安全性

Q4: CSRF以及state字段

之后补充

这几个问题欢迎评论区探讨

登录QQ-Golang实现

可参考：Go 语言实现 QQ 扫码登陆，AppId和AppKey使用该博主所申请的，代码写的也很可以，我也没啥好补充的。代码