Почему google Oauth verifyIdToken (версия javascript nodejs) не использует секрет клиента?

Я тестирую Google Singin для приложения SPA js + nodejs. Я добавил это:

<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), известной только на стороне сервера, так что никто другой, получающий токен, не может аутентифицировать этого пользователя. Что мне не хватает?


node.js google-signin google-oauth google-api-nodejs-client
person user1658162    schedule 23.12.2016    source источник
comment
Секрет клиента используется только в том случае, если вы запрашиваете доступ к дополнительным данным у Google с вашего внутреннего сервера, например автономный доступ к данным контакта, календаря или Диска пользователя. Секрет используется сервером для обмена кодом аутентификации из клиентского приложения на токены доступа для получения аутентифицированных данных. В вашем случае звучит так, будто вы просто передаете базовые данные пользователя, содержащиеся в токене идентификатора (подписанный JWT), на свой сервер для проверки личности пользователя. Если вам не нужен доступ к каким-либо аутентифицированным ресурсам Google с вашего сервера, вам не нужен токен доступа и секрет.   -  person Steven    schedule 24.12.2016
comment
Вот сообщения в блоге, объясняющие вариант использования только аутентификации: android-developers.googleblog.com/2016/01/ и вариант авторизации для доступа к API: android-developers.googleblog.com/2016/02/   -  person Steven    schedule 24.12.2016

Ответы (2)


arrow_upward
1
arrow_downward

Похоже, что созданный вами клиент является публичным клиентом, секрет клиента используется в частном клиенте.

Изменить: мне очень жаль, что я использовал термин частный клиент вместо конфиденциального клиента. В основном у нас есть 2 типа клиентов в Oauth2

  1. Публичные клиенты: - это клиенты, которым не нужен секрет клиента.

  2. Частные клиенты: - У этих клиентов есть секрет клиента.

Я не могу дать вам точного ответа на вопрос, почему вы не можете увидеть свой секрет клиента, поскольку я раньше не работал с этими конкретными библиотеками, однако мне кажется, что, возможно, вы создали публичный клиент вместо Секретный.

person UchihaItachi    schedule 23.12.2016
comment
теперь я действительно запутался ... какая разница с точки зрения googleAuth между общедоступным и частным клиентом? в следующем руководстве не говорится о публичном или частном клиенте: developers.google .com / identity / sign-in / web / sign-in - person user1658162; 24.12.2016

arrow_upward
1
arrow_downward

Я верю, что знаю ответ,

См. Здесь: https://firebase.google.com/docs/auth/admin/verify-id-tokens

Он объясняет, как самостоятельно проверить подпись JWT (если хотите), и это также то, что делает google-auth-library. Внутри библиотеки найдите verifySignedJwtWithCertsAsync() внутри oauth2client.js. Google обрабатывает подписание JWT, используя собственный закрытый ключ во время процесса федеративного входа. К тому времени, когда JWT будет возвращен вам и отправлен в библиотеку аутентификации, он уже будет подписан. Это здорово, потому что вам никогда не придется прикасаться к закрытому ключу. Он надежно хранится в Google, вы просто позволяете Google обрабатывать эту часть. Затем, когда вы отправляете JWT на свой сервер, утверждение идентификатора ключа в заголовке позволяет библиотеке аутентификации знать, какой открытый ключ использовать для его декодирования. Если открытый ключ не может его расшифровать, значит, аутентификация не удалась.

Наконец, убедитесь, что токен ID был подписан закрытым ключом, соответствующим детскому требованию токена. Получите открытый ключ из https://www.googleapis.com/robot/v1/metadata/x509/[email protected] и используйте библиотеку JWT для проверки подписи. Используйте значение max-age в заголовке Cache-Control ответа от этой конечной точки, чтобы знать, когда обновлять открытые ключи.

Если все вышеперечисленные проверки успешны, вы можете использовать тему (под) идентификатора токена в качестве uid соответствующего пользователя или устройства.

person Allen    schedule 08.04.2020