Питання по Google OAuth 2: Чому я можу розшифрувати токен без ключа «client secret»?

Раніше я писав сайт, де за допомогою Google APIs Client Library for PHP можна було перевіряти зашифрований токен, що приходить від користувача, який логінеться через OAuth 2. Тоді я прочитав документацію, підключив бібліотеку, передав Client ID та Client secret і все працювало як належить.

Зараз же пишу аналогічну інтеграцію, але за допомогою Google APIs Node.js Client. На моє здивування, цей клієнт може розшифровувати токен і без ключа Client secret:

let GoogleAuth = require('google-auth-library');

let promise = new Promise( (resolve, reject) =>
{
  let authFactory = new GoogleAuth();

  let client = new authFactory.OAuth2(); // Сюди можна було передати Secret key, але чомусь працює і без нього

  client.verifyIdToken
  (
    req.body.token
    ,googlePlusClientId // Це мій "публічний ключ
    ,(err, login) =>
    {
      if(err)
      {
        req.log.error(err);
        return res.send( {message: 'Токен недійсний!'} );
      }
      
      resolve( login.getAttributes() ); // Тут вже розшифровані дані
    }
  );
});

Як таке може бути? В документації сказано:

Visit the Google API Console to obtain OAuth 2.0 credentials such as a client ID and client secret that are known to both Google and your application. The set of values varies based on what type of application you are building. For example, a JavaScript application does not require a secret, but a web server application does.

Взагалі-то «JavaScript application» звучить не однозначно, і на скільки я зрозумів, то тут мається на увазі більше «client-side JavaScript application», але не «backend JavaScript application»... хоча, може тут таки мається на увазі обидва варіанти.

Я собі уявляю, що токен повинен бути зашифрований таким чином, щоб його можна було розшифрувати лише за допомогою Client secret.

Я помиляюсь? Ніхто не підкаже?

Оновлення від 07.09.2016 00:30
Хм, виявляється слово «токен» не однозначне, коли ми говоримо про авторизацію через OAuth 2 — є access token, ID token та refresh token.

Раніше я постійно використовував ID token. Виявляється у нього є три частини розділені через крапку, причому перші дві із них закодовані через base64-формат (необхідна інформація міститься саме в них), а третя частина — вже справді зашифрована і використовується Node.js-клієнтом для верифікації даного токена. Тобто, якщо на сервер приходить ID токен, то Node.js-клієнт його може верифікувати навіть без ключа Client secret

Я використовую базовий scope, і схоже, що Client secret треба використовувати для «глибшого» рівня доступу до інформації користувача...

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті