谷歌的 OAuth2 documentation for Go ，标题为“使用 Go 验证用户”并涉及书架示例应用程序，建议将配置文件信息存储在 cookie 中。例如，参见 profileFromSession() 函数，也可以是 visible in GitHub .该文档说“因为配置文件信息存储在 session 中，应用程序可以检索它而无需再次从 Google+ API 获取它”。它存储 Google+ ID 和 DisplayName(通过 plus.Person .ID 和 plus.Person.DisplayName)。
但这不是不好的做法吗？客户是否可以轻松伪造用户配置文件，让他们通过在 cookie 中放入不同的用户 ID 来访问您应用程序中的任何用户数据？
从 cookie 获取配置文件时，它首先检查 token 是否有效，但仅在本地检查 token 结构是否包含访问 token 以及它是否已过期，而不会与 Google 的服务器进行任何通信。客户端当然有可能使用任意配置文件 ID 构造一个假 cookie。 cookie 已加密(参见 http://www.gorillatoolkit.org/pkg/sessions#NewCookieStore )，但只是对称加密，使加密 key 成为此次攻击的唯一障碍。
谷歌的 equivalent Java OAuth2 documentation似乎在做同样的事情。
我是不是误会了什么？我无法相信 Google 的文档会推荐如此不安全的东西。
最佳答案
示例使用 HMAC以防止 cookie 伪造。
更多细节:示例使用 Gorilla 的 securecookie访问 cookie 的包。此 securecookie 包使用 crypto/hmac用于签署和验证 cookie 的包。
如果 cookie 通过 HTTPS 发送，则第三方无法窃取 cookie。
securecookie 包的加密功能在防止伪造或窃取 cookie 方面不起作用。
关于go - 为什么 Google 的 OAuth2 文档建议将配置文件 ID 存储在 cookie 中？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/46092368/