Oauth

Oauth2.0

作用: 客户端和资源所有者 颁发令牌 授权机制
三方: 1、服务提供方 2、用户 3、客户端

授权码

先申请授权码 后用其获取令牌

• 优势
  • 避免令牌泄漏 前端 授权码 后端存储令牌
• 流程
  • A前端请求B 请求授权码
  • B要求用户登录 后问用户是否同意给予A网站授权 同意跳转redirect_uri
  • A拿到授权码在后端向B请求令牌
  • B颁发令牌 access_token

https://b.com/oauth/authorize?
  response_type=code&
  client_id=CLIENT_ID&
  redirect_uri=CALLBACK_URL&
  scope=read
  //说明
  response_type 返回授权码code
  client_id 让B知道是谁在请求
  redirect_uri B接受或拒绝请求后的跳转网址
  scope 表示要求的授权范围(只读)

https://b.com/oauth/token?
 client_id=CLIENT_ID&
 client_secret=CLIENT_SECRET&
 grant_type=authorization_code&
 code=AUTHORIZATION_CODE&
 redirect_uri=CALLBACK_URL
 //说明
 client_secret 参数是保密的 只能在后端发请求
 grant_type 授权方式 授权码/隐藏式/密码式/凭证

implicit(隐藏式)

有些 Web 应用是纯前端应用，没有后端必须将令牌储存在前端
A 网站提供一个链接，要求用户跳转到 B 网站，授权用户数据给 A 网站使用。
用户跳转到 B 网站，登录后同意给予 A 网站授权。这时，B 网站就会跳回redirect_uri参数指定的跳转网址，并且把令牌作为 URL 参数，传给 A 网站
https://a.com/callback#token=ACCESS_TOKEN

password(密码式)：

用户高度信任的应用 使用密码 申请令牌
第一步，A 网站要求用户提供 B 网站的用户名和密码。拿到以后，A 就直接向 B 请求令牌
第二步，B 网站验证身份通过后，直接给出令牌。注意，这时不需要跳转，而是把令牌放在 JSON 数据里面，作为 HTTP 回应，A 因此拿到令牌。

client credentials(客户端凭证)

适用于没有前端的命令行应用，即在命令行下请求令牌
不是针对用户的，即有可能多个用户共享同一个令牌。
第一步，A 应用在命令行向 B 发出请求。
第二步，B 网站验证通过以后，直接返回令牌。

参考文档

OAuth 2.0 的一个简单解释：https://www.ruanyifeng.com/blog/2019/04/oauth_design.html
OAuth 2.0 的四种方式：https://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html
GitHub OAuth 第三方登录示例教程：https://www.ruanyifeng.com/blog/2019/04/github-oauth.html