Gmail API внезапно перестал работать с [Ошибка: неавторизованный_клиент]

Там, где я работаю, мы используем Google Apps for Work. В течение последних 9 месяцев мы использовали Gmail API (~ 2000 запросов в день), чтобы получать новые электронные письма для наших учетных записей электронной почты службы поддержки.

Вот как мы его изначально настроили:

  1. Перейдите на страницу https://console.developers.google.com/project/.
  2. Нажмите на проект (или создайте новый)
  3. Нажмите на API и аутентификацию
  4. Нажмите на учетные данные
  5. Нажмите «Создать новый идентификатор клиента».
  6. Нажмите на учетную запись службы
  7. Загрузите JWT (json) для учетной записи.
  8. Следуйте краткому руководству node.js с токеном установленного/собственного типа для того же учетную запись и авторизовать ее через консоль. Токены JWT не работали, если мы не сделали этот шаг, один раз для каждой учетной записи.

Мы сделали это для каждой из наших отдельных учетных записей электронной почты службы поддержки, чтобы избежать необходимости включать делегирование на уровне домена для любой из них в консоли администратора. Затем мы смогли пройти аутентификацию с помощью токенов, используя официально поддерживаемую npm библиотеку googleapis, примерно так:

var google = require('googleapis');

var jwtClient = new google.auth.JWT(
    token.client_email,
    null,
    token.private_key,
    ['https://www.googleapis.com/auth/gmail.readonly'],
    '[email protected]'
);

jwtClient.authorize(function(err, tokens) {
    if (err) {
        return cb(err);
    }

    var gmail = google.gmail('v1');
    var requestOptions = {
        auth: jwtClient,
        userId: 'me',
        id: messageId,
        format: 'raw'
    };

    gmail.users.messages.get(requestOptions, function(err, response) {
        if (err) {
            return cb(err);
        }
        // do stuff with the response
    });
});

Как я уже сказал, мы использовали это в течение длительного времени и никогда не было никаких проблем. Вчера около 10:00 по московскому времени все учетные записи перестали проходить аутентификацию в одно и то же время, и jwtClient.authorize() внезапно вернула ошибку [Error: unauthorized_client].

Я попытался сделать то же самое с новым токеном в новой учетной записи службы (веб-интерфейс для получения токена сильно изменился за последние 9 месяцев), и он возвращает ту же ошибку.

Версия googleapis, которую мы использовали, была 0.9.7, но мы также не можем заставить аутентификацию JWT работать в новейшей версии.

Мы создали тикет со службой поддержки Google API, но сотрудник службы поддержки, с которым мы говорили, никогда раньше не читал спецификации Gmail API и в конечном итоге не смог нам помочь, поэтому он перенаправил нас сюда, чтобы связаться с команда инженерной поддержки API.

Мы заметили, что аутентификация работает, если мы включаем область делегирования на уровне домена в консоли администратора, но мы бы предпочли этого не делать. Нам не нужно олицетворять учетные записи, и мы предпочли бы использовать отдельный JWT для каждой учетной записи.


person brismuth    schedule 10.03.2016    source источник
comment
@Tholle, спасибо за предложение. Я посмотрел на список причин, и я не верю, что они применимы. Все учетные записи перестали работать в одно и то же время, и мы не меняли пароли и не отзывали доступ, и все они являются служебными учетными записями, поэтому их не следует ограничивать 25 токенами обновления. Что касается использования, все учетные записи/токены используются ежедневно.   -  person brismuth    schedule 11.03.2016
comment
Я также пытался получить новые токены, и мы получаем ту же ошибку.   -  person brismuth    schedule 11.03.2016
comment
На данный момент, без каких-либо изменений с нашей стороны, все наши токены теперь работают с перерывами. Это наводит меня на мысль, что Google находится в процессе развертывания исправления.   -  person brismuth    schedule 11.03.2016
comment
Как вы авторизовали каждую учетную запись службы для конкретной учетной записи электронной почты службы поддержки? Я не вижу, чтобы это происходило в 7 шагах, которые вы описали.   -  person Brandon Jewett-Hall    schedule 12.03.2016
comment
@BrandonJewett-Холл извините за это! Я совершенно забыл указать этот шаг, я добавил его как шаг 8. Оглядываясь назад, я задаюсь вопросом, была ли причина, по которой шаг 8 работал для нас раньше, из-за ошибки, и, возможно, проблемы, с которыми мы начали сталкиваться, были из-за того, что они его исправили. .   -  person brismuth    schedule 12.03.2016
comment
В этом случае кажется, что вы можете пропустить создание учетной записи службы и использовать обычный 3LO для авторизации клиента. Затем вы должны сохранить и повторно использовать полученный токен обновления вместо JWT.   -  person Brandon Jewett-Hall    schedule 12.03.2016
comment
@BrandonJewett-Hall Наша цель — предоставить нашему серверу токен с неограниченным сроком действия, который он может использовать для аутентификации с помощью API gmail. Из того, что я прочитал в документах, похоже, это именно тот вариант использования учетных записей служб. Это неправильно?   -  person brismuth    schedule 12.03.2016
comment
Согласно документам сервисных аккаунтов, сервисные аккаунты обычно используются для доступа к непользовательским данным. , но также может получить доступ к пользовательским данным, если ему предоставлены привилегии на уровне домена. процесс аутентификации установленного приложения больше подходит для вашего случая использования. Он будет производить долгоживущие токены обновления.   -  person Brandon Jewett-Hall    schedule 12.03.2016
comment
Если вместо этого мы используем поток аутентификации установленного приложения, сможем ли мы продолжать получать токены обновления бесконечно, или есть какой-то предел, после которого нам нужно будет повторно авторизоваться в браузере? Я посмотрел в документах, но не нашел прямого ответа.   -  person brismuth    schedule 12.03.2016
comment
Кроме того, наши звонки больше не терпят неудачу в этот момент. Вы работаете в Google в команде API и/или знаете, планируют ли они восстановить изменения в серверной части, которые нарушают нашу текущую настройку с учетными записями служб?   -  person brismuth    schedule 12.03.2016
comment
Установленный поток приложения позволяет автономное (неопределенное) обновление маркеров доступа. Описанный вами поток не поддерживается. Как сказал Брэндон, это нетипичное использование сервисных учетных записей. Тот факт, что это работало в прошлом, является скорее случайностью, чем разработанной функцией.   -  person Steve Bazyl    schedule 12.03.2016
comment
@SteveBazyl и Брэндон, спасибо за информацию. Мы планируем изменить нашу службу, чтобы вместо этого использовать поток аутентификации установленного приложения.   -  person brismuth    schedule 12.03.2016
comment
И да, откат был но он временный.   -  person Steve Bazyl    schedule 12.03.2016
comment
@SteveBazyl спасибо, что сообщили нам и откатили, если это было для нас. Мы изменим наши услуги на новый поток как можно скорее.   -  person brismuth    schedule 12.03.2016
comment
@SteveBazyl теперь мы перешли на поток аутентификации установленного приложения и больше не используем хакерский поток аутентификации JWT, который у нас был раньше. Еще раз спасибо за ваши предложения.   -  person brismuth    schedule 13.03.2016


Ответы (1)


Оказывается, используемый нами процесс авторизации никогда не поддерживался и, вероятно, был нарушен из-за исправления ошибки со стороны Google.

В комментариях к вопросу @Brandon Jewett-Hall и @Steve Bazyl рекомендовал нам использовать вместо этого установлен поток аутентификации приложения, так как он поддерживает неограниченное обновление маркеров доступа и поддерживается.

Дополнительную информацию о различных потоках аутентификации можно найти в документах Google API.

person brismuth    schedule 12.03.2016