为什么 google Oauth verifyIdToken(javascript nodejs 版本)不使用 client-secret?
Why google Oauth verifyIdToken (javascript nodejs version) doesn't use client-secret?
我正在为 SPA js+nodejs 应用程序测试 google singin。
我添加了这个:
<script src="https://apis.google.com/js/platform.js" async defer></script>
还有这些:
<meta name="google-signin-client_id" content="YOUR_CLIENT_ID.apps.googleusercontent.com">
<div class="g-signin2" data-onsuccess="onSignIn"></div>
在 html5/js 客户端。
遵循本指南:
https://developers.google.com/identity/sign-in/web/sign-in
当用户验证库时获取令牌并将其传递给服务器,如下所述:
https://developers.google.com/identity/sign-in/web/backend-auth
在服务器端 (nodejs) 使用此函数验证令牌:
client.verifyIdToken(
token,
CLIENT_ID,
// Or, if multiple clients access the backend:
//[CLIENT_ID_1, CLIENT_ID_2, CLIENT_ID_3],
function(e, login) {
var payload = login.getPayload();
var userid = payload['sub'];
// If request specified a G Suite domain:
//var domain = payload['hd'];
});
我的问题是:什么时候使用 client_secret?因为我使用 CLIENT_ID 前端从 google 获取身份验证令牌,所以我使用 CLIENT_ID 服务器端进行令牌验证。我认为可以使用仅在服务器端已知的 client_secret(即 SECRET)来验证令牌,这样获得令牌的其他人就无法对该用户进行身份验证。
我错过了什么?
看来您创建的客户端是一个Public客户端,客户端密钥用于私人客户端。
编辑:很抱歉我使用了私人客户一词而不是机密客户。
基本上我们在 Oauth2
中有两种类型的客户端
Public 客户端:- 这些是不需要客户端密码的客户端。
私人客户:- 这些客户有一个客户秘密。
关于为什么您看不到您的客户机密,我不能给您一个非常肯定的答案,因为我以前没有使用过这些特定的库,但是
在我看来,您可能创建了 public 客户端而不是机密客户端。
我相信我有答案,
看这里:https://firebase.google.com/docs/auth/admin/verify-id-tokens
它解释了如何自行检查 JWT 的签名(如果需要),这也是 google-auth-library
正在做的事情。在库内,在 oauth2client.js
内搜索 verifySignedJwtWithCertsAsync()
。 Google 在联合登录过程中使用他们自己的私钥处理 JWT 的签名。当 JWT 返回给您并发送到 auth 库时,它已经被签名了。这很棒,因为您永远不必触摸私钥。它安全地存储在 Google,您只需让 Google 处理该部分。然后,当您将 JWT 发送到您的服务器时,header 中的密钥 id 声明让 auth 库知道使用哪个 public 密钥对其进行解码。如果 public 密钥无法解码,则身份验证失败。
Finally, ensure that the ID token was signed by the private key corresponding to the token's kid claim. Grab the public key from https://www.googleapis.com/robot/v1/metadata/x509/securetoken@system.gserviceaccount.com and use a JWT library to verify the signature. Use the value of max-age in the Cache-Control header of the response from that endpoint to know when to refresh the public keys.
If all the above verifications are successful, you can use the subject (sub) of the ID token as the uid of the corresponding user or device.
我正在为 SPA js+nodejs 应用程序测试 google singin。 我添加了这个:
<script src="https://apis.google.com/js/platform.js" async defer></script>
还有这些:
<meta name="google-signin-client_id" content="YOUR_CLIENT_ID.apps.googleusercontent.com">
<div class="g-signin2" data-onsuccess="onSignIn"></div>
在 html5/js 客户端。 遵循本指南:
https://developers.google.com/identity/sign-in/web/sign-in
当用户验证库时获取令牌并将其传递给服务器,如下所述:
https://developers.google.com/identity/sign-in/web/backend-auth
在服务器端 (nodejs) 使用此函数验证令牌:
client.verifyIdToken(
token,
CLIENT_ID,
// Or, if multiple clients access the backend:
//[CLIENT_ID_1, CLIENT_ID_2, CLIENT_ID_3],
function(e, login) {
var payload = login.getPayload();
var userid = payload['sub'];
// If request specified a G Suite domain:
//var domain = payload['hd'];
});
我的问题是:什么时候使用 client_secret?因为我使用 CLIENT_ID 前端从 google 获取身份验证令牌,所以我使用 CLIENT_ID 服务器端进行令牌验证。我认为可以使用仅在服务器端已知的 client_secret(即 SECRET)来验证令牌,这样获得令牌的其他人就无法对该用户进行身份验证。 我错过了什么?
看来您创建的客户端是一个Public客户端,客户端密钥用于私人客户端。
编辑:很抱歉我使用了私人客户一词而不是机密客户。 基本上我们在 Oauth2
中有两种类型的客户端Public 客户端:- 这些是不需要客户端密码的客户端。
私人客户:- 这些客户有一个客户秘密。
关于为什么您看不到您的客户机密,我不能给您一个非常肯定的答案,因为我以前没有使用过这些特定的库,但是 在我看来,您可能创建了 public 客户端而不是机密客户端。
我相信我有答案,
看这里:https://firebase.google.com/docs/auth/admin/verify-id-tokens
它解释了如何自行检查 JWT 的签名(如果需要),这也是 google-auth-library
正在做的事情。在库内,在 oauth2client.js
内搜索 verifySignedJwtWithCertsAsync()
。 Google 在联合登录过程中使用他们自己的私钥处理 JWT 的签名。当 JWT 返回给您并发送到 auth 库时,它已经被签名了。这很棒,因为您永远不必触摸私钥。它安全地存储在 Google,您只需让 Google 处理该部分。然后,当您将 JWT 发送到您的服务器时,header 中的密钥 id 声明让 auth 库知道使用哪个 public 密钥对其进行解码。如果 public 密钥无法解码,则身份验证失败。
Finally, ensure that the ID token was signed by the private key corresponding to the token's kid claim. Grab the public key from https://www.googleapis.com/robot/v1/metadata/x509/securetoken@system.gserviceaccount.com and use a JWT library to verify the signature. Use the value of max-age in the Cache-Control header of the response from that endpoint to know when to refresh the public keys.
If all the above verifications are successful, you can use the subject (sub) of the ID token as the uid of the corresponding user or device.