OpenId Connect问题 - 授权代码流程(OAuth 2.0)

Question

我正面临着OpenId Connect的自定义实现.但是(总有一个但是)我有些疑惑:

我理解获取access_token和id_token的过程,除了OP向客户端提供authorization_code的步骤.如果是通过重定向完成的(使用重定向uri)

HTTP/1.1 302 Found
Location: https://client.example.org/cb?
code=SplxlOBeZQQYbYS6WxSbIA
&state=af0ifjsldkj

• 最终用户能够看到授权码吗？它不会过期？想象一下,我们抓住了它,我们稍后使用(几天后)它是一个安全漏洞吗？状态是否应该在令牌端点中过期？

流程继续,我们得到了客户端Access_token和id_token客户端.

• 如何在Access_tokenOP方面使用？它应该存储在数据库中？或者自我包含验证它所需的信息？你会推荐什么？
• 在客户端,两个令牌都应该在每个请求中发送？

最后一个疑问,如果我们Access_token存在一个id_token是用于在分离的令牌中表示授权和身份验证？

额外的疑惑: 我知道获取访问令牌的过程,但我怀疑OP如何生成和发送,它验证每个请求附带的access_token

• OP如何知道访问令牌是有效的？据我所知,OP应该说access_token有效/无效.应该有一些方法来检查它吗？如果令牌没有存储在DB中,它如何知道令牌代表有效的经过身份验证的用户？
• 将access_token存储在cookie中是一个坏主意吗？因为有时我们会调用一些web服务,并且我们希望将access_token作为参数发送.还是有另一种解决方法？
• 访问令牌应该如何存储在客户端中,例如,在ASP.NET中,在会话中？

非常感谢你们所有人,一旦你给我解释,我就会放弃投票并标记答案.谢谢!

Answer 1

最终用户能够看到授权码吗？

是.虽然,即使可以看到授权代码,令牌请求也要求发送客户端的秘密(浏览器没有看到)

它不会过期？想象一下,我们抓住了它,我们稍后使用(几天后)这是一个安全漏洞？状态是否应该在令牌端点中过期？

规范说授权代码应该过期.请参阅https://tools.ietf.org/html/rfc6749#section-4.1.2.

如何在OP端使用Access_token？它应该存储在数据库中？或者自我包含验证它所需的信息？你会推荐什么？

如果您希望能够撤销令牌,则应将访问令牌存储在OP上.如果不这样做,令牌将采用JWT格式(自包含)......但是如果你想要能够撤销它,无论它是否是JWT,你都应该存储它.

在客户端,两个令牌都应该在每个请求中发送？

不,只是访问令牌.

最后一个疑问,如果我们有一个Access_token,id_token的存在是用于表示separeted令牌中的授权和身份验证？

是的,它们是用于不同目的的单独令牌.访问令牌用于授权,Id令牌是自包含的,用于与客户端通信,用户通过身份验证.

OP如何知道访问令牌是有效的？据我所知,OP应该说access_token有效/无效.应该有一些方法来检查它吗？如果令牌没有存储在DB中,它如何知道令牌代表有效的经过身份验证的用户？

请参阅如何验证资源服务器的OAuth 2.0访问令牌？关于在让客户端发出请求之前资源服务器应如何验证访问令牌的想法.

将access_token存储在cookie中是个坏主意？因为有时我们会调用一些web服务,我们希望将access_token作为参数发送.还是有另一种解决方法？

我假设您正在使用授权代码授权流程(...来自您的问题).如果是这种情况,首先,授权代码从OP而不是访问令牌传回的原因是访问令牌可以保持隐藏在服务器端 - 远离浏览器本身.使用授权代码授权流程,访问令牌应保持在浏览器之外.如果您想直接从浏览器向资源服务器发送api请求,请查看oauth2隐式流程(https://tools.ietf.org/html/rfc6749#section-4.2).

访问令牌应该如何存储在客户端中,例如,在ASP.NET中,在会话中？

在OAuth2的OpenID Connect风格中,访问令牌用于offline_access(即在经过身份验证的"会话"之外).访问令牌可以在用户会话期间使用,但最好将刷新令牌存储在数据库中,以便客户端应用程序可以在需要时请求新的访问令牌,只要刷新令牌有效即可.即使用户的身份验证过期.访问令牌应该是短暂的,因此将其存储在数据库中是一种选择,但不是必需的.