Почему использовать ClientLogin для веб-приложений в Google API — плохая идея?

Question

Я только сегодня получил Google API, чтобы разрешить некоторые пользователи нашего сайта могут загружать видео в учетную запись YouTube нашей организации. Я не хочу, чтобы наши пользователи знали наше имя пользователя и пароль, а хочу дать им возможность загружать видео на YouTube или нет.Если они решают это сделать, они устанавливают флажок и нажимают кнопку «Отправить».

В руководстве для разработчиков я снова и снова вижу, что ClientLogin, который мне кажется лучшим вариантом для реализации того, что я хочу, не является хорошей идеей для аутентификации пользователей в веб-приложениях.«AuthSub для веб-приложений», похоже, не лучший механизм для того, что я хочу реализовать!

Есть идеи, что делать?

Спасибо

Answer 1

Поигравшись с API Google и API других поставщиков видеоуслуг, я многое узнал об аутентификации.oAuth и AuthSub — это два метода, которые Google использует для аутентификации сторонних веб-приложений в учетной записи пользователя.

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

1. Когда веб-приложению требуется доступ к службе Google пользователя, оно выполняет вызов AuthSub к службе прокси-сервера авторизации Google.
2. Служба авторизации в ответ открывает страницу запроса доступа.Эта страница, управляемая Google, предлагает пользователю предоставить или запретить доступ к службе Google.Сначала пользователю может быть предложено войти в свою учетную запись.
3. Пользователь решает, предоставить или запретить доступ к веб-приложению.Если пользователь отказывает в доступе, он перенаправляется на страницу Google, а не обратно в веб-приложение.
4. Если пользователь предоставляет доступ, служба авторизации перенаправляет пользователя обратно в веб-приложение.Перенаправление содержит токен авторизации, рассчитанный на одно использование;его можно обменять на долгосрочный токен.
5. Веб-приложение обращается к сервису Google с запросом, используя токен авторизации, выступая в качестве агента для пользователя.
6. Если служба Google распознает токен, она предоставляет запрошенные данные.

http://code.google.com/apis/accounts/docs/AuthSub.html#AuthProcess

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

Преимущества этих методов перед старым школьным именем пользователя и паролем (на мой взгляд) следующие:

1. Повышенная безопасность для пользователя:Пользователю не нужно будет сообщать вам свое имя пользователя и пароль, ему необходимо войти в систему Google, и вы получите токен доступа, который вы будете использовать для дальнейших вызовов API.Пользователь может отозвать доступ к вашему приложению изнутри Google, если захочет.
2. Этот процесс может дать пользователю уверенность в том, что ваше приложение является «законным».Если пользователю нужно пройти через Google, чтобы войти в систему и разрешить ваше приложение, это может выглядеть хорошо, если ваш домен зарегистрирован в Google.
3. Токен можно повысить до токена сеанса:Это означает, что вам не нужно просить пользователя войти в систему каждый раз, когда вам нужно запросить доступ к учетной записи пользователя Google, просто используйте токен сеанса (который вы должны где-то надежно сохранить), и все готово.
4. Как только вы поймете процесс, аутентификация пользователей станет довольно простой.
5. (непроверено) Если пользователь меняет свой пароль, вам не нужно обновлять токен безопасности.
6. Наконец, если вы используете oAuth, вы можете создать интерфейс, который позволит вам легко аутентифицировать пользователей при подключении к другим веб-сервисам, таким как Vimeo!

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

Код аутентификации пользователей с помощью AuthSub можно найти здесь, он практически готов к использованию.просто обязательно сохраните $_SESSION['sessionToken'] в более постоянном месте, например в базе данных.

http://code.google.com/apis/youtube/2.0/developers_guide_php.html#AuthSub_for_Web_Applications

Answer 2

ClientLogin здесь не является предпочтительным механизмом, поскольку ваше приложение вынуждено обрабатывать учетные данные пользователя.Если личность пользователя необходимо установить на срок, превышающий один сеанс, вам придется хранить учетные данные, и это не идеально — компрометация вашего сервера приведет к компрометации пользователей Google.Таким образом, ClientLogin не подходит для вашего приложения.

Вы посмотрели Google OAuth?Он довольно элегантно решает проблему обработки паролей и является общепринятым стандартом.

Answer 3

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

Я не знаю, есть ли лучший способ сделать это с помощью AuthSub или других методов аутентификации.