OIDC / OAuth - 检索 SID Cookie
OIDC / OAuth - Retrieve SID Cookie
正在研究OIDC，有一个理解上的问题...
上下文：
我想使用 Google（使用 OIDC 协议）在 Whosebug 上注册。
所以EndUser还没有注册
- EndUser 点击登录 google
- Whosebug 重定向到 https://accounts.google.com/o/oauth2/auth (accounts.google.com)
- EndUser 同意并使用凭证登录
- Google 检查凭证并通过存储 SID cookie[=54= 注册 endUser ] 通过响应头
set-cookie: SID=...;Domain=.google.com;Path=/;Expires=...;Priority=HIGH
- Google 重定向到 Whosebug
- ~~ Whosebug 可以访问域 google.com 上的 SID cookie 存储 ~~
- Whosebug 知道用户已通过身份验证
问题
~~ 为什么 Whosebug 在重定向时可以访问域 google.com 上的 SID cookie？ ~~
编辑
抱歉，Whosebug 没有访问 SID cookie 的权限！
我现在的问题是：
Whosebug 如何知道用户已通过身份验证？因为会话 cookie 是由 google...
设置的
我无法在 Chrome 版本 94.0.4606.81 中重现该内容。
我保留了整个注册过程的网络日志，只看到 Google cookie 转到 Google 和 Whosebug cookie 转到 Whosebug。
screenshot of Google Consent request
screenshot of Stack Overflow request
TL;DR -- Google 给你一个代码，你给 Whosebug 并且 Whosebug 用 Google.
验证代码
OAuth2.0/OIDC 规范定义了几种方式，Google 和 Whosebug 可以就用户身份验证和授权安全地进行通信。
当我学习它时，我必须克服的主要障碍是我期望它会比实际更简单。
Takahiko Kawasaki (@takahiko-kawasaki) 发布了一个方便的参考 “所有 OAuth 2.0 流程的图表和电影”
https://darutk.medium.com/diagrams-and-movies-of-all-the-oauth-2-0-flows-194f3c3ade85“流程”是用户、身份验证服务器（Google，在本例中）和“客户端”（在本例中为 Whosebug）采取的一系列步骤。
Whosebug 正在使用“验证码”流程，这是文章中的第一个流程。
下面是对所发生情况的稍微简化的描述。
1) 重定向到 Google
当您在 Whosebug 上单击“用 google 签名 in/up”按钮时，它会将您的浏览器重定向到 accounts.google.com，并在查询字符串上使用一些参数：
- response_type: 这告诉 Google 使用哪个“流”。在这种情况下，它会给 Whosebug 一个代码。
- client_id: 这告诉 Google 授权请求是针对 Whosebug 的。 Whosebug 之前在他们的 Google 开发者帐户中进行了设置。
- scope: 这告诉 Google Whosebug 想要从用户的 Google 帐户访问什么（在这种情况下，只是电子邮件和个人资料信息）
- state: 这是 Google 将发回 Whosebug 的字符串。看起来里面有一堆东西，包括如何重新连接 Whosebug 会话，但我可能弄错了。
- redirect_uri: 这是 URL，Google 将在完成登录过程后将用户送回。
2) 重定向回 Whosebug
当您在 Google 端完成后，Google 会将您重定向回 Whosebug URL，并在查询字符串中添加一些新内容。
- state: 这与 Whosebug 发送到 Google 的数据相同。它现在由 Google 发回，因此当 Whosebug 将您发送到 Google 登录时，它可以使用它从中断的地方继续。
- code: 这是一个字符串，表示用户已通过身份验证。 Whosebug 可以使用此代码一次来验证您确实进行了身份验证并从 Google.
获得了一两个令牌
- scope: 这些是 Google 实际允许的范围。它可能与 Whosebug 在上一步中请求的不同。
- authuser:我不知道这是什么。我不认为这是 OAuth 标准
- 提示：我不知道这是什么。我不认为这是 OAuth 标准
3) Whosebug 使用 Google
检查
在这两个重定向之后，Whosebug 有一个授权码。
Whosebug 将代码连同 Google 之前分配给 Whosebug 的秘密字符串一起发送到 Google。
我在我的浏览器网络跟踪中看不到这种情况，因为它在 Whosebug 和 Google 之间，但我认为 Whosebug 接受身份令牌和授权令牌，两者都是 JWT 格式。
这些令牌已签名，因此 Whosebug（或任何人，真的）可以验证它们实际上是由 Google 发送的并且在传输过程中未被修改。这些令牌的有效负载包含有关用户的信息，例如姓名、电子邮件地址等。
注意：Google 授权令牌可能是一个随机的唯一字符串（“不透明令牌”），但我在这里假设它是一个 JWT。如果它是不透明的，则有一个额外的步骤，Whosebug 使用它从 Google.
中获取用户信息
正在研究OIDC，有一个理解上的问题...
上下文：
我想使用 Google（使用 OIDC 协议）在 Whosebug 上注册。
所以EndUser还没有注册
- EndUser 点击登录 google
- Whosebug 重定向到 https://accounts.google.com/o/oauth2/auth (accounts.google.com)
- EndUser 同意并使用凭证登录
- Google 检查凭证并通过存储 SID cookie[=54= 注册 endUser ] 通过响应头
set-cookie: SID=...;Domain=.google.com;Path=/;Expires=...;Priority=HIGH - Google 重定向到 Whosebug
- ~~ Whosebug 可以访问域 google.com 上的 SID cookie 存储 ~~
- Whosebug 知道用户已通过身份验证
问题
~~ 为什么 Whosebug 在重定向时可以访问域 google.com 上的 SID cookie？ ~~
编辑
抱歉，Whosebug 没有访问 SID cookie 的权限！ 我现在的问题是： Whosebug 如何知道用户已通过身份验证？因为会话 cookie 是由 google...
设置的我无法在 Chrome 版本 94.0.4606.81 中重现该内容。
我保留了整个注册过程的网络日志，只看到 Google cookie 转到 Google 和 Whosebug cookie 转到 Whosebug。
screenshot of Google Consent request
screenshot of Stack Overflow request
TL;DR -- Google 给你一个代码，你给 Whosebug 并且 Whosebug 用 Google.
验证代码OAuth2.0/OIDC 规范定义了几种方式，Google 和 Whosebug 可以就用户身份验证和授权安全地进行通信。 当我学习它时，我必须克服的主要障碍是我期望它会比实际更简单。
Takahiko Kawasaki (@takahiko-kawasaki) 发布了一个方便的参考 “所有 OAuth 2.0 流程的图表和电影” https://darutk.medium.com/diagrams-and-movies-of-all-the-oauth-2-0-flows-194f3c3ade85“流程”是用户、身份验证服务器（Google，在本例中）和“客户端”（在本例中为 Whosebug）采取的一系列步骤。
Whosebug 正在使用“验证码”流程，这是文章中的第一个流程。
下面是对所发生情况的稍微简化的描述。
1) 重定向到 Google
当您在 Whosebug 上单击“用 google 签名 in/up”按钮时，它会将您的浏览器重定向到 accounts.google.com，并在查询字符串上使用一些参数：
- response_type: 这告诉 Google 使用哪个“流”。在这种情况下，它会给 Whosebug 一个代码。
- client_id: 这告诉 Google 授权请求是针对 Whosebug 的。 Whosebug 之前在他们的 Google 开发者帐户中进行了设置。
- scope: 这告诉 Google Whosebug 想要从用户的 Google 帐户访问什么（在这种情况下，只是电子邮件和个人资料信息）
- state: 这是 Google 将发回 Whosebug 的字符串。看起来里面有一堆东西，包括如何重新连接 Whosebug 会话，但我可能弄错了。
- redirect_uri: 这是 URL，Google 将在完成登录过程后将用户送回。
2) 重定向回 Whosebug
当您在 Google 端完成后，Google 会将您重定向回 Whosebug URL，并在查询字符串中添加一些新内容。
- state: 这与 Whosebug 发送到 Google 的数据相同。它现在由 Google 发回，因此当 Whosebug 将您发送到 Google 登录时，它可以使用它从中断的地方继续。
- code: 这是一个字符串，表示用户已通过身份验证。 Whosebug 可以使用此代码一次来验证您确实进行了身份验证并从 Google. 获得了一两个令牌
- scope: 这些是 Google 实际允许的范围。它可能与 Whosebug 在上一步中请求的不同。
- authuser:我不知道这是什么。我不认为这是 OAuth 标准
- 提示：我不知道这是什么。我不认为这是 OAuth 标准
3) Whosebug 使用 Google
检查在这两个重定向之后，Whosebug 有一个授权码。 Whosebug 将代码连同 Google 之前分配给 Whosebug 的秘密字符串一起发送到 Google。
我在我的浏览器网络跟踪中看不到这种情况，因为它在 Whosebug 和 Google 之间，但我认为 Whosebug 接受身份令牌和授权令牌，两者都是 JWT 格式。
这些令牌已签名，因此 Whosebug（或任何人，真的）可以验证它们实际上是由 Google 发送的并且在传输过程中未被修改。这些令牌的有效负载包含有关用户的信息，例如姓名、电子邮件地址等。
注意：Google 授权令牌可能是一个随机的唯一字符串（“不透明令牌”），但我在这里假设它是一个 JWT。如果它是不透明的，则有一个额外的步骤，Whosebug 使用它从 Google.
中获取用户信息