OpenId Connect 问题 - 授权代码流程 (OAuth 2.0)
OpenId Connect Questions -Authorization Code Flow (OAuth 2.0)
我面临 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
- 最终用户能够看到该授权码吗？它不会过期？想象一下我们抓住它并稍后（几天后）使用它是一个安全漏洞吗？状态是否应该在令牌端点中过期？
流程继续，我们在客户端获得了 Access_token 和客户端中的 id_token。
- 如何在 OP 端使用
Access_token？它应该存储在数据库中？或者包含验证它所需的信息？您会推荐什么？
- 在客户端，每个请求都应该发送两个令牌？
最后一个疑问，如果我们有一个 Access_token 存在一个 id_token 是为了在分离的令牌中表示授权和身份验证吗？
额外疑惑：
我知道获取访问令牌的过程，但我怀疑 OP 在生成和发送后如何验证每个请求 access_token
- OP 如何知道访问令牌有效？据我所知，OP 应该说 access_token 是 valid/invalid。应该有一些方法来检查它吧？如果令牌未存储在数据库中，它如何知道令牌代表有效的经过身份验证的用户？
- 将 access_token 存储在 cookie 中是个坏主意吗？因为有时我们调用一些网络服务，我们想发送 access_token 作为参数。或者还有其他解决方法？
- access token应该如何存储在Client中，例如，在ASP.NET，在session中？
非常感谢大家，只要您给我解释，我就会点赞并标记为答案。
谢谢！
The end-user is able to see that authorization code?
是的。虽然，即使可以看到授权代码，令牌请求也需要发送客户端的秘密（浏览器看不到）
it does not expires? Imagine we catch it and we use later (some days later) It is a security hole? Should the state be expired in the Token Endpoint?
规范说授权码应该过期。参见 https://www.rfc-editor.org/rfc/rfc6749#section-4.1.2。
How the Access_token should be used on the OP side ? It should be stored in a database? Or be self containing of the information required to validate it ?What would you recommend?
如果您希望能够撤销令牌，则应将访问令牌存储在 OP 上。如果您不这样做，令牌将采用 JWT 格式（独立的）...但是如果您希望能够撤销它，无论它是否是 JWT，您都应该存储它。
And in the client-side , both tokens should be sent in every request?
不，只是访问令牌。
And the last doubt, if we have an Access_token the existance of an id_token is for representing authorization and authentication in separeted tokens?
是的，它们是用于不同目的的单独令牌。访问令牌用于授权，Id 令牌是自包含的，用于向客户端传达用户已通过身份验证。
How the OP knows an access token is valid? As far as i know, the OP should say that an access_token is valid/invalid. There should be some way to check it right? How it gets to know that a token represents a valid authenticated user if it is not stored in DB?
请参阅 How to validate an OAuth 2.0 access token for a resource server? 关于资源服务器在让来自客户端的请求通过之前应如何验证访问令牌的想法。
It´s a bad idea to store access_token in a cookie? because sometimes we call to some webservices and we want to send access_token as parameter. Or there is another workaroundsolution?
我假设您正在使用授权码授予流程（...来自您的问题）。如果是这种情况，那么首先从 OP 而不是访问令牌传回授权代码的原因是访问令牌可以隐藏在服务器端——远离浏览器本身。在授权代码授予流程中，访问令牌应该远离浏览器。如果您想直接从浏览器向资源服务器发送 api 请求，请查看 oauth2 隐式流 (https://www.rfc-editor.org/rfc/rfc6749#section-4.2).
How the access token should be stored in the Client , for example, in ASP.NET, in the session?
在 OAuth2 的 OpenID Connect 风格中，访问令牌用于 offline_access（即在经过身份验证的“会话”之外）。访问令牌可以在用户会话期间使用，但最好将刷新令牌存储在数据库中，以便您的客户端应用程序可以在需要时请求新的访问令牌，只要刷新令牌有效。 .即使用户的身份验证已过期。访问令牌应该是短期的，因此将其存储在数据库中是一种选择，但不是必需的。
我面临 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
- 最终用户能够看到该授权码吗？它不会过期？想象一下我们抓住它并稍后（几天后）使用它是一个安全漏洞吗？状态是否应该在令牌端点中过期？
流程继续，我们在客户端获得了 Access_token 和客户端中的 id_token。
- 如何在 OP 端使用
Access_token？它应该存储在数据库中？或者包含验证它所需的信息？您会推荐什么？ - 在客户端，每个请求都应该发送两个令牌？
最后一个疑问，如果我们有一个 Access_token 存在一个 id_token 是为了在分离的令牌中表示授权和身份验证吗？
额外疑惑： 我知道获取访问令牌的过程，但我怀疑 OP 在生成和发送后如何验证每个请求 access_token
- OP 如何知道访问令牌有效？据我所知，OP 应该说 access_token 是 valid/invalid。应该有一些方法来检查它吧？如果令牌未存储在数据库中，它如何知道令牌代表有效的经过身份验证的用户？
- 将 access_token 存储在 cookie 中是个坏主意吗？因为有时我们调用一些网络服务，我们想发送 access_token 作为参数。或者还有其他解决方法？
- access token应该如何存储在Client中，例如，在ASP.NET，在session中？
非常感谢大家，只要您给我解释，我就会点赞并标记为答案。 谢谢！
The end-user is able to see that authorization code?
是的。虽然，即使可以看到授权代码，令牌请求也需要发送客户端的秘密（浏览器看不到）
it does not expires? Imagine we catch it and we use later (some days later) It is a security hole? Should the state be expired in the Token Endpoint?
规范说授权码应该过期。参见 https://www.rfc-editor.org/rfc/rfc6749#section-4.1.2。
How the Access_token should be used on the OP side ? It should be stored in a database? Or be self containing of the information required to validate it ?What would you recommend?
如果您希望能够撤销令牌，则应将访问令牌存储在 OP 上。如果您不这样做，令牌将采用 JWT 格式（独立的）...但是如果您希望能够撤销它，无论它是否是 JWT，您都应该存储它。
And in the client-side , both tokens should be sent in every request?
不，只是访问令牌。
And the last doubt, if we have an Access_token the existance of an id_token is for representing authorization and authentication in separeted tokens?
是的，它们是用于不同目的的单独令牌。访问令牌用于授权，Id 令牌是自包含的，用于向客户端传达用户已通过身份验证。
How the OP knows an access token is valid? As far as i know, the OP should say that an access_token is valid/invalid. There should be some way to check it right? How it gets to know that a token represents a valid authenticated user if it is not stored in DB?
请参阅 How to validate an OAuth 2.0 access token for a resource server? 关于资源服务器在让来自客户端的请求通过之前应如何验证访问令牌的想法。
It´s a bad idea to store access_token in a cookie? because sometimes we call to some webservices and we want to send access_token as parameter. Or there is another workaroundsolution?
我假设您正在使用授权码授予流程（...来自您的问题）。如果是这种情况，那么首先从 OP 而不是访问令牌传回授权代码的原因是访问令牌可以隐藏在服务器端——远离浏览器本身。在授权代码授予流程中，访问令牌应该远离浏览器。如果您想直接从浏览器向资源服务器发送 api 请求，请查看 oauth2 隐式流 (https://www.rfc-editor.org/rfc/rfc6749#section-4.2).
How the access token should be stored in the Client , for example, in ASP.NET, in the session?
在 OAuth2 的 OpenID Connect 风格中，访问令牌用于 offline_access（即在经过身份验证的“会话”之外）。访问令牌可以在用户会话期间使用，但最好将刷新令牌存储在数据库中，以便您的客户端应用程序可以在需要时请求新的访问令牌，只要刷新令牌有效。 .即使用户的身份验证已过期。访问令牌应该是短期的，因此将其存储在数据库中是一种选择，但不是必需的。