#oauth
#oauth
Вопрос:
Я пытаюсь использовать двусторонний oauth, чтобы позволить мобильному клиенту входить в созданный мной api, однако я не могу полностью настроить правильный рабочий процесс для этого, и все руководства, кажется, говорят что-то другое.
Из того, что я прочитал в двуногой версии, ключ потребителя oauth и секрет потребителя специально назначаются пользователю, а токены не используются. Таким образом, когда пользователь входит в систему, он (или его устройство) должен будет предоставить свой потребительский ключ и секрет, и мы можем использовать это для проверки их личности. Но что потом? Получает ли клиентское устройство какой-либо токен, который они используют для доступа к API, или они отправляют информацию о пользователе с каждым запросом?
И можно ожидать, что пользователь запомнит только имя пользователя и пароль, как нам перейти от имени пользователя и пароля на клиентском устройстве к ключу потребителя и секрету для отправки на сервер?
Ответ №1:
У вас не должно быть пары потребительский ключ / секрет для каждого клиентского устройства. Понятие OAuth «потребитель» — это конкретный сайт или разработчик, использующий API для аутентификации перед вами. Кто создает пары имя пользователя / пароль? Это конкретно ваши учетные записи пользователей, или вы ищете, чтобы пользователи могли входить в вас с помощью учетных записей Yahoo, Google и т.д.?
В любом случае, я бы ожидал, что у пользователей будут имя пользователя и пароль, а не потребительский ключ и потребительский секрет.
Комментарии:
1. Да, мы хотели бы, чтобы пользователи создавали имя пользователя / пароли специально для нашего сервиса, мы не пытаемся интегрироваться с Google, Yahoo и т.д. И да, мы хотели бы использовать имя пользователя и пароль, но не уверены, какую роль они играют в oauth. Ни одна из примеров реализаций проверки oauth, которые я видел, ничего не делала с паролем.
2. Звучит так, как будто вам нужны имена пользователей и пароли, а не OAuth. Что вы стремитесь получить от OAuth? Может помочь дополнительная информация о вашей архитектуре.
3. Я пока не очень хорошо знаком с двуногим OAuth, но одно из основных преимуществ использования OAuth в целом заключается в том, что вам никогда не нужно сохранять фактическое имя пользователя и пароль пользователя, а вместо этого хранить какие-либо учетные данные OAuth (например, ключ / секрет). Если мобильное устройство пользователя украдено, они могут войти на ваш веб-сайт, используя имя пользователя / пароль, и деавторизовать учетные данные OAuth, хранящиеся на устройстве, так что теперь вор не может войти с помощью устройства. Учетные данные OAuth также могут иметь ограниченные разрешения, поэтому, даже если они скомпрометированы, никто не сможет, например, изменить ваш пароль.
Ответ №2:
Двухэтапный OAuth удаляет отдельный сервер аутентификации / authZ, который напрямую взаимодействует с клиентом, который в противном случае присутствует в трехэтапном OAuth. Это, безусловно, связано с токенами (доступа). Клиентское устройство получит токен и сможет использовать его до истечения срока его действия.
Преимущество этой настройки в том, что вам не нужно беспокоиться о безопасности client_id / secret при каждом вызове API. Отправка client_id / secret при каждом вызове является базовой аутентификацией, и это не рекомендуется. Вместо этого, используя OAuth, вам нужно беспокоиться только о безопасности client_id / secret при вызове API, используемом для получения токена (например, один раз за время действия каждого токена). И если токен скомпрометирован, у него есть TTL, тогда как client_id / secret этого не делают.
Идентификатор клиента / секрет не известны конечному пользователю, который предоставляет свои собственные учетные данные пользователя. Ожидается, что клиентское приложение будет обрабатывать согласование client_id / secret для токена.