.NET Gmail OAuth2 для нескольких пользователей

Question

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

Документация, похоже, не охватывает этот прецедент. Например, https://developers.google.com/api-client-library/dotnet/guide/aaa_oauth говорит, что токены клиента должны храниться в client_secrets.json - что, если у нас есть 1000 клиентов, что тогда?

Учетные записи службы предназначены для информации, не являющейся пользователем, а скорее данными приложения. Кроме того, если я использую GoogleWebAuthorizationBroker, и пользователь удалил доступ, или жетоны истекли, я не хочу, чтобы мое серверное приложение сервера открыло веб-браузер, поскольку это, похоже, делает.

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

Есть ли ссылка на то, как это можно сделать?

Answer 1

Хотя ответ @ hurcane более чем правдоподобен (не пробовал), это то, что я получил за последние несколько дней. Я действительно не хотел, чтобы де/сериализации данных из файла, чтобы получить эту работу, так что я своего рода пюре это решение

1. веб-приложение, чтобы получить одобрение клиента
   • Использование AuthorizationCodeMvcApp от Google. Apis.Auth.OAuth2.Mvc и документация
2. Хранить в результате доступа & токенов обновления в БД
3. Использование AE.Net.Mail сделать первоначальный доступ по протоколу IMAP с доступом лексем
4. Backend также использует AE.Net.Mail для доступа
   • Если токен истек, используйте токен обновления, чтобы получить новый токен доступа.

Я не сделал отправляющей часть, но я полагаю, SMTP будет работать аналогичным образом.

код основан на SO & Публикаций:

T = объект EF, содержащих лексемы данные

ic = new ImapClient("imap.gmail.com", t.EmailAddress, t.AccessToken, AuthMethods.SaslOAuth, 993, true); 

Чтобы получить обновленный маркер доступа (требуется обработка ошибок) (использует тот же интерфейс, как шаг # 1 выше)

using (var wb = new WebClient()) 
      { 
       var data = new NameValueCollection(); 
       data["refresh_token"] = refresh; 
       data["client_id"] = "(Web app OAuth id)"; 
       data["client_secret"] = "(Web app OAuth secret)"; 
       data["grant_type"] = "refresh_token"; 

       var response = wb.UploadValues(@"https://accounts.google.com/o/oauth2/token", "POST", data); 
       string Tokens = System.Text.Encoding.UTF8.GetString(response); 
       var token = Newtonsoft.Json.JsonConvert.DeserializeObject<dynamic>(Tokens); 
       at = token.access_token; 
       return at; 
      } 

Answer 2

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

Я думаю, что окончательный ответ - это настраиваемый IAuthorizationCodeFlow, который поддерживает только доступ с существующим токеном и не будет выполнять процесс авторизации. Вероятно, поток будет имитировать ответ, который возникает, когда пользователь нажимает кнопку «Отклонить» на интерактивном потоке. То есть любая потребность в получении токена авторизации просто вернет «отклоненный» AuthorizationResult.

Мой проект по-прежнему находится в фазе R & D, и я пока еще не делаю доказательства концепции. Я предлагаю этот ответ в надежде, что он поможет кому-то другому разработать конкретное решение.