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

Question

我正面临着OpenId Connect的自定义实现。但是（总是有一个但是）我有一些疑问：

我理解获取acces_token和id_token的过程，除了OP向客户端提供authorization_code的步骤。如果它是通过重定向完成的（使用重定向uri）

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

< li >最终用户能够看到授权码吗？它不会过期吗？想象一下，我们捕获了它，并在稍后(几天后)使用它，这是一个安全漏洞吗？令牌endpoint中的状态是否应该过期？

流程继续，我们在客户端获得了Access_token和客户端中的id_token。

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

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

额外的疑问：我知道获取访问令牌的过程，但我怀疑OP一旦生成并发送，它将如何验证每个请求附带的access_token

< li > How如何知道访问令牌是有效的？据我所知，OP应该说一个access_token有效/无效。应该有办法检查一下吧？如果一个令牌没有存储在DB中，它如何知道这个令牌代表一个有效的经过身份验证的用户？ < li >将access_token存储在cookie中是个坏主意吗？因为有时我们调用一些web服务，我们希望将access_token作为参数发送。或者有另一个变通的解决办法？ < li >访问令牌应如何存储在客户端中，例如，在ASP.NET的会话中？

非常感谢你们所有人，只要你们给我解释，我会投赞成票并标记为答案。谢谢

Answer 1

最终用户是否能够看到该授权代码？

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

它不会过期？想象一下，我们抓住它，然后（几天后）使用它，这是一个安全漏洞？令牌endpoint中的状态是否应过期？

规范说授权码应该过期。看见https://www.rfc-editor.org/rfc/rfc6749#section-4.1.2.

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

如果您希望能够撤销令牌，访问令牌应该存储在OP上。如果您不这样做，令牌将采用JWT格式（自包含）…但是，如果您希望能够撤销它，无论它是否是JWT，您都应该存储它。

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

不，只是访问令牌。

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

是的，它们是用于不同目的的独立令牌。访问令牌用于授权，Id令牌是自包含的，用于向客户端通知用户已通过身份验证。

OP如何知道访问令牌是有效的？据我所知，OP应该说一个access_token有效/无效。应该有办法检查一下吧？如果一个令牌没有存储在DB中，它如何知道这个令牌代表一个有效的经过身份验证的用户？

请参见如何验证资源服务器的OAuth 2.0访问令牌？关于资源服务器应该如何在允许来自客户端的请求通过之前验证访问令牌的想法。

将access_token存储在cookie中不是一个好主意？因为有时我们调用一些web服务，我们希望将access_token作为参数发送。或者有另一个变通的解决办法？

我假设您正在使用授权代码授予流程（...从你的问题）。如果是这种情况，首先从 OP 而不是访问令牌传回授权代码的原因是，访问令牌可以隐藏在服务器端 - 远离浏览器本身。使用授权代码授予流时，访问令牌应远离浏览器。如果要直接从浏览器向资源服务器发送 api 请求，请查看 oauth2 隐式流 （https://www.rfc-editor.org/rfc/rfc6749#section-4.2）。

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

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