如何使用“jti”、“client_secret”和“exp”来验证“id_token”？

Question

我正在做这个“教程”

https://developers.google.com/identity/sign-in/web/backend-auth

看来我明白了这个概念背后的想法。

基本上，用户通过谷歌对自己进行身份验证，获得一个“证书”，证明他就是他，并将其发送给我，我在谷歌（公钥）的帮助下验证该证书，并且我可以为用户创建会话它属于“sub”中的id，因为我可以确定它是由google（“iss”）为我（“aud”）创建的，而不是很久以前（“exp”）。

然而，正如我所看到的，令牌有效时有 1 小时的间隙。我不太明白，为什么正好1小时。我猜原因是令牌可以以某种方式被窃取（具体是如何窃取的？），然后用户就可以被攻击者冒充。如果这就是原因，为什么不是 5 分钟或 1 分钟，因为它是一次性令牌，仅用于登录，就在 google 登录发生之后？

我还...我看到一个“jti”（令牌 ID）和一个客户端密钥。当我在 Google 控制台上创建凭据时，我还收到了一个 client_secret （以及 client_id）。但是我没有在任何地方使用它，它的目的是什么？

我应该使用 jti 来确保没有其他人想要使用 id_token 吗？如果这是这样做的方法（我对此表示怀疑，它会导致使用的“jti”数据库不断增长）为什么本教程中没有提到这一点？

我按照自己的方式完成了教程，并且它正在发挥作用 - 然而这些问题仍然困扰着我。总结一下：

完成所有工作后，教程建议...

1.我需要对“jti”做什么吗？如果我不使用它来做任何事情，我会留下安全漏洞吗？

2.对于客户端秘密几乎同样的问题 - 我是否会因为不对其进行任何操作而留下安全漏洞？（那我为什么会有它？）

3. “exp”怎么样？我知道 verify() 方法可以处理它，但是我必须用它做任何事情吗？（如果重要的话，为什么 1 小时，为什么这么长，如果不重要，为什么不是 Long.maxValue 之类的？）

我认为根据那里写的内容，我了解正在发生的事情，而且，我觉得没有完全理解正在发生的事情，（所有这些字段和值）我可能会造成巨大的安全差距 - 对我来说，似乎没有所有这些，身份验证可能工作得很好，但是为什么它们存在呢？

Answer 1

您可以在此处获取此详细信息：

https://developers.google.com/identity/gsi/web/reference/js-reference#CredentialResponse

标头

{
  "alg": "RS256",
  "kid": "f05415b13acb9590f70df862765c655f5a7a019e", // JWT signature
  "typ": "JWT"
}

有效载荷

{
  "iss": "https://accounts.google.com", // The JWT's issuer
  "nbf":  161803398874,
  "aud": "314159265-pi.apps.googleusercontent.com", // Your server's client ID
  "sub": "3141592653589793238", // The unique ID of the user's Google Account
  "hd": "gmail.com", // If present, the host domain of the user's GSuite email address
  "email": "elisa.g.beckett@gmail.com", // The user's email address
  "email_verified": true, // true, if Google has verified the email address
  "azp": "314159265-pi.apps.googleusercontent.com",
  "name": "Elisa Beckett",
                            // If present, a URL to user's profile picture
  "picture": "https://lh3.googleusercontent.com/a-/e2718281828459045235360uler",
  "given_name": "Elisa",
  "family_name": "Beckett",
  "iat": 1596474000, // Unix timestamp of the assertion's creation time
  "exp": 1596477600, // Unix timestamp of the assertion's expiration time
  "jti": "abc161803398874def"
}