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。

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

最后一个疑问，如果我们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中，它如何知道令牌代表有效的经过身份验证的用户？

请参阅How to validate an OAuth 2.0 access token for a resource server?，了解资源服务器在让客户端发出请求之前应如何验证访问令牌。

将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（即在经过身份验证的“会话”之外）。访问令牌可以在用户会话期间使用，但最好将刷新令牌存储在数据库中，以便客户端应用程序可以在需要时请求新的访问令牌，只要刷新令牌有效即可。即使用户的身份验证过期。访问令牌应该是短暂的，因此将其存储在数据库中是一种选择，但不是必需的。

OpenId Connect问题 - 授权代码流程（OAuth 2.0）

1 个答案: