1
eason1874 2021-12-25 16:07:33 +08:00
OAuth2 有两种模式。一种适合客户端,直接与开放网站连接,这就是你想要的无 Code 版本,直接就给 Token
另一种适合 Web 页面,用户授权回调跳转给 Code ,你的服务器再拿 Code 去拿 Token 。因为网页跳转的网址可能会被浏览器、代理、安全软件等多种软件记录,直接给 Token 会增加泄露风险,所以给一次性 Code ,你服务器拿到了再去换。Code 有效期很短而且只能用一次,不怕泄露 |
2
wdssmq 2021-12-25 17:46:10 +08:00
除了支付接口外,大部分都是,你向 API 发起一个请求,API 返回对应信息,API 不会主动向外发起请求,一些非 web 端的也没法主动通知;
登录验证后,只能由用户通过浏览器跳转将鉴权信息带回 app 端,虽然请求的 access token 属于用户,用户自身可信,但是用户环境不可信。 不管 code 还是 token ,app 信不信并没人在乎,你拿着 code 或 token 去请求时对面认不认才是关键,甚至已经发了正确的 token ,但是中间发现该应用违规,直接 ban appid ,关联该应用的全部 token 都失效; |
3
oott123 2021-12-25 18:20:06 +08:00 via Android 1
因为你的前提:
> 绝大多数场景下,应用程序 Foobar 会把自己和 google 交流的 access token 也给客户,让客户每次请求带上,是因为现在流行服务端不保持状态,所以不缓存这个 token 。 是错误的。使用 code 流程授权,应用不应该把 token 提供给用户端。 |
4
Newyorkcity OP |
5
eason1874 2021-12-25 18:57:47 +08:00
@Newyorkcity #4 不会,因为正确的流程是用户授权回调得到 Code 之后,在服务端换取 Token ,不在客户端
|
6
kejialiu 2021-12-25 19:58:21 +08:00 via Android
code 是经过客户端转发给 Foobar ,而不是 Google 直接发给 Foobar 的,Foobar 无法直接验证真伪,得自己去找 Google 问一下(通过 https ,可以验明 Google 正身)。
但如果用 SAML 这样的协议,可以不用回 Google 二次验证,因为认证结果(Assertion)是带签名的,签名用的公钥在前期配置过程中就已经同步给 Foobar 了 |
7
Newyorkcity OP @kejialiu 我知道要二次验证,因为 foobar 被动接收的地址不知道到底是什么妖魔鬼怪再向它发消息。。。我的疑惑是,干嘛不第一次就发 token ,非得先发个 code ,然后你来验证了我才给你 token 。。。。。。。难道是强迫应用程序必须进行验证,强迫应用程序提高安全性?
|
8
wdssmq 2021-12-25 21:36:18 +08:00
![QQ 截图 20211225212310.png]( https://s2.loli.net/2021/12/25/AenbjgR5mt4PcDv.png)
v 站的谷歌登录,code 在浏览器控制台就能看到; |
9
ysc3839 2021-12-25 21:41:00 +08:00 via Android 1
有 code 的是用户授权第三方服务的情况吧?此时要确保只有被授权的服务能拿到实际的 access token ,所以先返回一个 code 给客户端,客户端把 code 提交给服务器,服务器拿着 code 和 app secret 去请求才能拿到 access token ,任何中间方拿到了 code 都不能拿到 access token
|
10
wyx119911 2021-12-26 02:42:38 +08:00
就是为了防止拦截到 access token 呀,这样可以保证 token 始终在服务器不外泄出去
|
11
Newyorkcity OP |
12
kejialiu 2021-12-26 09:44:36 +08:00 via Android 1
服务器之间的通信,不会经过浏览器,https 保证了没有中间人(除非 Google 脑抽泄露了私钥或者把私钥共享给了不靠谱的第三方 cdn 之类)
|
13
oneisall8955 2021-12-26 10:03:18 +08:00 via Android 1
楼主是不是觉得用 code 请求获取 token 是多余的,那就是这种 password 模式?
https://www.oauth.com/oauth2-servers/access-tokens/password-grant/ 相比较 code 模式如下: https://www.oauth.com/oauth2-servers/server-side-apps/authorization-code/ |
14
Newyorkcity OP @kejialiu 『不会经过浏览器』 -> 言下之意是数据经过浏览器的话在这一步可能会有风险。why ?什么风险呢?
@oneisall8955 谢谢。我粗看了 password 模式,里面说 as there is no way to add multifactor authorization to this flow, and your options for detecting brute force attacks are more limited. This flow should not be used in practice. emmm ,但为什么不用 code 直接发 token 会导致 no way to add multifactor authorization 和 options for detecting brute force attacks are more limited 呢?(直接拿到 token 不要 code 并不意味着应用不做第二步——向授权服务器验证 token 有效——在有 code 的流程里,这一步是应用拿着 code 去验证并拿回 token——我是想问为什么不一开始就让应用程序拿到 token ,然后这一步让应用拿着 token 去验证) |
15
wyx119911 2021-12-26 12:08:43 +08:00 1
@Newyorkcity “至少要发一次 token 给应用”,给的是应用服务器,而不是应用前端。保证 token 只在服务器间流转就 能保证次次不外泄。只要 token 带给前端,就无法避免外泄。
|
16
horsley 2021-12-26 14:22:45 +08:00
可以从票据特性的角度重新理解下:
按你的例子,第一方 Google 有自己的身份票据,要授权给 Foobar ,授权后 Foobar 最终会得到 access_token ,长期有效,可刷新,可用于请求各种资源,因此 access_token 暴露在浏览器跳转等过程就不安全,可能被中间人获取,可以被重放使用。 而通过使用 code 做转换依据则好得多,code 的设计为短时间单次有效,用完即弃,正常浏览器跳转时间很短,无法被重放使用。 |
17
ysc3839 2021-12-26 16:06:03 +08:00 via Android
@Newyorkcity 中间方指的是除了被授权应用,其他能获得 code 的人
|
18
kejialiu 2021-12-26 22:12:30 +08:00 via Android
@Newyorkcity 尽量减少不必要的暴露。客户端不能完全信任,浏览器也有正经的和不正经的,正经浏览器也可能装了恶意插件。当然,真出问题的可能性不大,但你要做的事情足够敏感时就不得不防
|