因此，我了解OIDC在大多数情况下的工作方式。我知道如果我们直接使用OIDC（而无需为我们处理），我知道如何解决这个问题。浏览器只需将其 access_token 发送给我们所有异步调用，我们可以根据OIDC提供商托管的OIDC userInfo 服务对其进行验证。
但是，AWS实现并未将这些常见的OIDC值暴露于浏览器，并且只给了我们他们的专有加密cookie，例如 awselb 。这很好，对于超级基本网站，您不在乎一旦授权用户实际对用户进行身份验证，但我们都在乎这两者。
当我们的回调击中回调时，我们还可以生成专有的“会话密钥”，并使用它而不是 awselb cookie ...但是似乎在重新发明了方向盘。 当然，必须有一种让我们的后端应用程序代码重复使用 awselb cookie来验证用户的身份？ aws文档，没有这样的WebService允许我们允许我们验证从我们的服务器代码中的cookie。
So, I understand how OIDC works for the most part. I know how to solve this question if we use OIDC directly (without AWS handling it for us). The browser would just send their access_token to us for all async calls, and we could verify it against the OIDC UserInfo service that's hosted by our OIDC provider.
The AWS implementation doesn't expose any of these common OIDC values to the browser though, and just gives us their proprietary encrypted cookies like AWSELB. This is fine, for super basic sites where you don't care about actually authenticating the user once they're authorized, but we care about both.
We could also generate a proprietary "session key" when our callback is hit, and use that instead of the AWSELB cookie... but it seems like reinventing the wheel. Certainly, there must be a way to let our backend application code just reuse the AWSELB cookie to verify the identity of user? AWS documentation mentions no such webservice to allow us to validate that cookie from our server code.
发布评论
评论（1）
负载平衡器将IDP的访问令牌作为标头提供：
x-amzn-oidc-accessToken;您应该能够针对IDP进行验证。它还在标题中提供用户索赔：x-amzn-oidc-data。请参阅
The load balancer provides the IdP's access token as a header:
x-amzn-oidc-accesstoken; you should be able to validate this against the IdP. It also provides user claims in a header:x-amzn-oidc-data.See https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html#user-claims-encoding