oauth - 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

最终用户能看到那个授权码吗？它不会过期？想象一下，我们捕获它并稍后使用(几天后)它是一个安全漏洞吗？ token 端点中的状态是否应该过期？

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

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

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

最后一个疑问，如果我们有 Access_token id_token 的存在用于在单独的 token 中表示授权和身份验证？

额外疑问:
我知道获取访问 token 的过程，但我怀疑 OP 在生成和发送后如何验证每个请求附带的 access_token

OP 如何知道访问 token 有效？据我所知，OP 应该说 access_token 有效/无效。应该有什么方法可以检查吧？如果 token 未存储在数据库中，它如何知道 token 代表有效的经过身份验证的用户？

将 access_token 存储在 cookie 中是一个坏主意吗？因为有时我们调用一些 web 服务，我们想发送 access_token 作为参数。或者有另一种解决方法？

访问 token 应该如何存储在 Client 中，例如，在 ASP.NET 中，在 session 中？

非常感谢大家，我会在你给我解释后立即投赞成票并标记为答案。
谢谢!

Answer 1

The end-user is able to see that authorization code?

是的。虽然，即使可以看到授权码， token 请求也需要发送客户端的 secret (浏览器看不到)

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?

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

And in the client-side , both tokens should be sent in every request?

不，只是访问 token 。

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?

是的，它们是用于不同目的的单独 token 。访问 token 用于授权，而 Id token 是自包含的，用于向客户端传达用户已通过身份验证的信息。

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?关于在让来自客户端的请求通过之前资源服务器应如何验证访问 token 的想法。

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 而不是访问 token 传回授权代码的原因是，访问 token 可以隐藏在服务器端——远离浏览器本身。在授权码授予流程中，访问 token 应位于浏览器之外。如果您想直接从浏览器向资源服务器发送 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 风格中，访问 token 用于 offline_access(即在经过身份验证的“ session ”之外)。访问 token 可以在用户 session 期间使用，但最好将刷新 token 存储在数据库中，以便您的客户端应用程序可以在需要时并且只要刷新 token 有效就可以请求新的访问 token 。 .即使用户的身份验证已过期。访问 token 应该是短暂的，因此将其存储在数据库中是一种选择，但不是必需的。