Почему это - плохая идея использовать ClientLogin для веб-приложений в Google API?
Я просто взял Google API сегодня, чтобы позволить некоторым пользователям нашего сайта загружать видео на нашу собственную организационную учетную запись YouTube. Я не хочу, чтобы наши пользователи знали наше имя пользователя и пароль, а скорее дали им опцию, если они хотят загрузить видео на YouTube или нет. Если они принимают решение сделать это, они проверяют флажок и поражают кнопку отправки.
Я продолжаю видеть, и в Разработчиках ведут тот ClientLogin, чтобы мне похож на наилучший вариант реализовать то, что я хочу сделать, не хорошая идея для аутентификации пользователя в сети applicaitons. "AuthSub для веб-приложений", кажется, не лучший механизм для того, что я хочу реализовать!
Какие-либо идеи о том, что сделать?
Спасибо
3 ответа
Поиграв с Google API и API других поставщиков видеоуслуг, я многое узнал об аутентификации. oAuth и AuthSub - это два метода, которые Google использует для аутентификации сторонних веб-приложений в учетной записи пользователя.
Поначалу процесс может показаться запутанным, но как только вы его поймете, это не так уж плохо. На следующем изображении показан процесс AuthSub.
- Когда веб-приложению требуется доступ к сервису Google пользователя, оно выполняет вызов AuthSub к сервису авторизации прокси Google.
- Служба авторизации отвечает, обслуживая страницу запроса доступа.Эта управляемая Google страница предлагает пользователю разрешить / запретить доступ к своей службе Google. Сначала пользователя могут попросить войти в свою учетную запись.
- Пользователь решает, разрешить или запретить доступ к веб-приложению. Если пользователь отказывает в доступе, он направляется на страницу Google, а не обратно в веб-приложение.
- Если пользователь предоставляет доступ, служба авторизации перенаправляет пользователя обратно в веб-приложение. Перенаправление содержит токен авторизации, пригодный для одноразового использования; его можно обменять на жетон-долгожитель.
- Веб-приложение обращается к службе Google с запросом, используя токен авторизации, чтобы действовать как агент для пользователя.
- Если служба Google распознает токен, она предоставляет запрошенные данные.
http://code.google.com/apis/accounts/docs/AuthSub.html#AuthProcess
Когда вы запрашиваете аутентификацию, и пользователь входит в свою учетную запись Google, прежде чем он / она предоставляет вашему приложению разрешение на выполнение каких-либо действий в своей учетной записи, и если ваш домен не был зарегистрирован в Google, пользователь получит неприятное красное поле, говорящее им быть осторожными, потому что приложение, к которому они собираются предоставить доступ, не зарегистрировано у них .
Преимущества этих методов перед старыми именем пользователя и паролем (на мой взгляд) следующие:
- Повышенная безопасность для пользователя: пользователю не нужно будет сообщать вам свое имя пользователя и пароль, у них есть для входа в Google, и вы получите токен доступа, который вы будете использовать для дальнейших вызовов API. Пользователь может отозвать доступ к вашему приложению изнутри Google, если захочет.
- Этот процесс может дать пользователю уверенность в том, что ваше приложение «Законно». Если пользователю нужно пройти через Google, чтобы войти в систему и разрешить ваше приложение, это может выглядеть хорошо, если ваш домен был зарегистрирован в Google.
- Маркер может быть повышен до маркера сеанса: это означает, что вам не нужно просить пользователя войти в систему каждый раз, когда вам нужно запросить доступ к учетной записи пользователя Google, просто используйте маркер сеанса (который вы должны безопасно сохранить где-нибудь) и все готово.
- Как только вы поймете процесс, аутентифицировать пользователей будет довольно просто.
- (непроверено) Если пользователь меняет свой пароль, вам не нужно обновлять токен безопасности.
- Наконец, если вы используете oAuth, вы можете создать интерфейс, который позволит вам легко аутентифицировать пользователей при подключении к другим веб-службам, таким как Vimeo!
С учетом всего вышесказанного, я думаю, вы можете понять, почему было бы плохой идеей использовать имя пользователя и пароли (что и делает ClientLogin) для подключения к учетной записи пользователя. Другие методы аутентификации позволяют делать то же самое (запрашивать доступ) и добавляют кучу преимуществ.
Код о том, как аутентифицировать пользователей с помощью AuthSub, можно найти здесь, это в значительной степени plug and play. просто убедитесь, что сохранили $ _SESSION ['sessionToken'] в более постоянном месте, таком как БД.
http://code.google.com/apis/youtube/2.0/developers_guide_php.html#AuthSub_for_Web_Applications
У меня была та же проблема, и в итоге я использовал ClientLogin. Если вы не хотите, чтобы ваши пользователи видели какую-либо часть процесса входа в систему, это подойдет.
Я не знаю, есть ли лучший способ сделать это с помощью AuthSub или других методов аутентификации.
ClientLogin не является предпочтительным механизмом здесь, потому что ваше приложение вынуждено обрабатывать учетные данные для входа для пользователя. Если идентификация пользователя должна быть установлена дольше, чем сеанс, вы будете вынуждены сохранить учетные данные, и это не идеально - компрометация вашего сервера приведет к компрометации для пользователей Google. Таким образом, ClientLogin не подходит для вашего приложения.
Вы смотрели Google OAuth ? Он довольно элегантно решает проблему обработки паролей и является установленным стандартом.