OAuth 2.0: Преимущества и варианты использования - почему?

Может ли кто-нибудь объяснить, что хорошего в OAuth2 и почему мы должны его реализовать? Я спрашиваю, потому что я немного смущен - вот мои текущие мысли:

Запросы OAuth1 (точнее, HMAC) кажутся логичными, понятными, легкими в разработке и действительно надежными.

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

И чтобы получить еще один токен доступа, вы используете токен обновления, который был передан одновременно с токеном доступа. Это делает токен доступа бесполезным с точки зрения безопасности?

Плюс, как недавно показал /r/netsec, SSL не все полностью безопасно, поэтому нажимать на TLS/SSL вместо надежного HMAC меня смущает.

OAuth утверждают, что это не около 100% безопасности, а получение и публикация. Это не совсем похоже на перспективу с точки зрения поставщика. Я вижу, что пытается сделать проект, когда упоминает 6 разных потоков, но это просто не подходит мне в голову.

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

ОТВЕТЫ

Ответ 1

Справочная информация. Я написал клиентские и серверные стеки для OAuth 1.0a и 2.0.

Оба OAuth 1.0a и 2.0 поддерживают двухстороннюю аутентификацию, где сервер уверен в идентификации пользователя, и трехсторонняя аутентификация, где сервер гарантирован поставщиком контента для идентификации пользователя. Трехсторонняя аутентификация заключается в том, что запросы авторизации и токены доступа вступают в игру, и важно отметить, что в OAuth 1 тоже есть.

Комплексный: трехсторонняя аутентификация

Основной смысл спецификаций OAuth - это поставщик контента (например, Facebook, Twitter и т.д.), чтобы обеспечить сервер (например, веб-приложение, которое хочет поговорить с поставщиком контента от имени клиента), что у клиента есть личность. То, что предлагает трехсторонняя аутентификация, - это возможность сделать это без того, чтобы клиент или сервер когда-либо нуждались в информации о деталях этого идентификатора (например, имя пользователя и пароль).

Без (?) слишком углубляясь в детали OAuth:

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

Теперь сервер может отправлять запросы поставщику контента от имени пользователя, передавая токен доступа.

Каждый обмен (клиент- > сервер, сервер- > поставщик контента) включает проверку общего секрета, но поскольку OAuth 1 может работать по незашифрованному соединению, каждая проверка не может передать секрет по проводу.

Это сделано, как вы уже отметили, с HMAC. Клиент использует секрет, который он разделяет с сервером, чтобы подписать аргументы для своего запроса на авторизацию. Сервер принимает аргументы, подписывает их сам с ключом клиента и может видеть, является ли он законным клиентом (в шаге 1 выше).

Эта подпись требует, чтобы клиент и сервер согласовали порядок аргументов (поэтому они подписывают точно такую ​​же строку), и одна из основных жалоб на OAuth 1 заключается в том, что для этого требуются как сервер, так и клиенты сортировать и подписывать одинаково. Это неудобный код, и он прав, или вы получаете 401 Unauthorized с небольшой помощью. Это увеличивает барьер для записи клиента.

Требовав, чтобы запрос авторизации работал по протоколу SSL, OAuth 2.0 устраняет необходимость сортировки и подписи аргументов вообще. Клиент передает свой секрет серверу, который проверяет его непосредственно.

Те же самые требования присутствуют в соединении поставщика сервера → , и после этого SSL, который удаляет один барьер для записи сервера, который обращается к службам OAuth.

Это делает вещи намного проще на шагах 1, 2 и 5 выше.

Итак, на этом этапе у нашего сервера есть токен постоянного доступа, который является эквивалентом имени пользователя/пароля для пользователя. Он может отправлять запросы поставщику контента от имени пользователя, передавая этот токен доступа как часть запроса (в качестве аргумента запроса, заголовка HTTP или данных формы POST).

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

Способ, который разрешен в OAuth 2, с токеном обновления. Ток обновления становится постоянным эквивалентом пароля, и он передается только через SSL. Когда серверу нужен доступ к службе контента, он обменивает токен обновления для краткосрочного токена доступа. Таким образом, все нюхательные HTTP-запросы выполняются с токеном, который истекает. Google использует 5-минутное истечение срока действия своих API-интерфейсов OAuth 2.

Таким образом, помимо токенов обновления, OAuth 2 упрощает все коммуникации между клиентом, сервером и поставщиком контента. И токены обновления существуют только для обеспечения безопасности при доступе к содержимому незашифрованного.

Двусторонняя аутентификация

Иногда, однако, сервер просто должен контролировать доступ к своему собственному контенту. Двусторонняя аутентификация позволяет клиенту аутентифицировать пользователя непосредственно с сервером.

OAuth 2 стандартизирует некоторые расширения для OAuth 1, которые широко используются. Тот, который я знаю лучше всего, был представлен Twitter как xAuth. Вы можете увидеть это в OAuth 2 как Учетные данные владельца ресурса.

По существу, если вы можете доверять клиенту учетные данные пользователя (имя пользователя и пароль), они могут обмениваться данными напрямую с поставщиком контента для токена доступа. Это делает OAuth гораздо более полезным для мобильных приложений - с трехсторонней аутентификацией вам необходимо встроить представление HTTP для обработки процесса авторизации с сервером контента.

С OAuth 1 это не было частью официального стандарта и требовало такой же процедуры подписания, как и все остальные запросы.

Я только что реализовал серверную часть OAuth 2 с учетными данными пароля владельца ресурса, и с точки зрения клиента получение токена доступа стало простым: запросить токен доступа с сервера, передать идентификатор/секрет клиента как HTTP-авторизацию заголовок и логин/пароль пользователя как данные формы.

Преимущество: Простота

Таким образом, с точки зрения разработчика основные преимущества, которые я вижу в OAuth 2, сокращены. Это не требует процедуры подписания запроса, что не совсем сложно, но, безусловно, неудобно. Это значительно сокращает работу, требуемую для того, чтобы действовать как клиент службы, где (в современном мобильном мире) вы больше всего хотите свести к минимуму боль. Сокращенная сложность на стороне сервера- > поставщика контента делает его более масштабируемым в центре обработки данных.

И он кодирует в стандартные расширения для OAuth 1.0a (например, xAuth), которые теперь широко используются.

Ответ 2

Я бы ответил на этот вопрос несколько иначе, и я буду очень точным и кратким, главным образом потому, что @Peter T ответил на все это.

Основным преимуществом, которое я вижу из этого стандарта, является соблюдение двух принципов:

  • Разделение проблем.
  • Отключить аутентификацию из веб-приложения, которое обычно обслуживает бизнес.

Таким образом,

  • Вы можете реализовать альтернативу Single SignOn: если у вас есть несколько приложений, которые доверяют одному STS. Что я имею в виду, одно имя пользователя для всех приложений.
  • Вы можете включить веб-приложение (клиент) для доступа к ресурсам, принадлежащим пользователю и не принадлежащим к веб-приложению (клиенту).
  • Вы можете поручить процесс аутентификации третьей стороне, которой вы доверяете, и не беспокоиться о проверке подлинности пользователя.