Блог

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

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

Есть ли какой-то обходной путь, когда мне нужно создать только одну учетную запись службы, переносимую между доменами, или какой-то удобный способ, например, поделиться URL-адресом, как мы делаем в потоке 3LO OAuth?

Кроме того, есть ли какая-либо альтернатива самой учетной записи службы, т. Е. Как я могу получить привилегию редактирования ресурсов всего домена в рамках 3LO OAuth?

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

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

Также важно отметить тот факт, что API календаря использует OAuth 2.0, поэтому вся аутентификация выполняется с использованием этого потока.

Ссылка

• Понимание Учетных записей Служб.