结合使用Google OIDC和代码流和PKCE

时间:2020-03-17 14:45:06

标签: oauth-2.0 single-page-application openid-connect google-identity pkce

经过反复试验后,我觉得Google OIDC在不提供客户机密的情况下不支持代码流: https://developers.google.com/identity/protocols/oauth2/native-app#exchange-authorization-code

根据SPA(https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13)的最新最佳实践,建议使用代码流+ PKCE处理身份验证。有人知道让Google代码流接受code_challenge而不是client_secret所需的任何技巧吗?也许是个假的秘密?

2 个答案:

答案 0 :(得分:5)

截至2020年8月,引用的最佳实践文档仍在草案中,并且正在积极更新-此处为总修订版:https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/。 Google的OAuth2实现尚未将PKCE的“进行中”推荐应用于网络应用。 SPA仍被指示使用Google在线文档https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow中的隐式流程。

PKCE(https://tools.ietf.org/html/rfc7636)的标准详细说明了它是作为缓解移动平台上发现的授权代码拦截攻击的缓解措施而开发的,最初是本机客户端建议实施的。 Google的“移动和桌面应用程序”文档确实指导开发人员使用PKCE授权代码流程。使用Google Android,iOS或Windows的客户将凭据类型与PKCE一起使用时,可以省略client_secret(请参阅刷新令牌参数表上的注释-并由Cristiano确认)。

现在人们已经认识到,PKCE消除了任何个公共客户端存储客户端机密的需要,因此可以用来淘汰隐式流,该隐式流始终具有包括返回的访问权限和重定向URI中的身份令牌。 https://developer.okta.com/blog/2019/05/01/is-the-oauth-implicit-flow-dead

IETF文件草案在2.1.1节中指出,这种认可可能会成为已发布的标准。

希望当最佳实践被接受时,Google将更新其实现,以消除对PKCE令牌请求的client_secret的要求。同时,看来我们别无选择,只能继续使用隐式流程编写SPA。

答案 1 :(得分:0)

好吧,我使用的是带有pkce的openId Connect授权代码,而在使用以下https://github.com/openid/AppAuth-Android的Android应用中未使用client_secret。

我只需要确保使用清单中的应用程序包名称设置了自定义方案,然后使用它在Google控制台上注册android凭据。