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

Question

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

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

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

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

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

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

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

Answer 1

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

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

Сложный: трехсторонняя аутентификация

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

Не вдаваясь (?) В детали OAuth:

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

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

Каждый обмен (клиент-> сервер, сервер-> контент-провайдер) включает проверку общего секрета, но, поскольку 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), которые сейчас широко используются.

Answer 2

Во-первых, как четко указано в аутентификации OAuth

OAuth 2.0 не является протоколом аутентификации.

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

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

Существует стандарт аутентификации пользователя с использованием OAuth: OpenID Connect, совместимый с OAuth2.

OpenID Connect ID Token - это подписанный JSON Web Token (JWT), который предоставляется клиентскому приложению наряду с обычным токеном доступа OAuth. Идентификатор Token содержит набор утверждений о сеансе аутентификации, в том числе идентификатор пользователя (подчиненного), идентификатор провайдера идентификации, выдавшего токен (iss), и идентификатор клиента, для которого этот токен был создан ( ауд).

В Go вы можете посмотреть на coreos / dex, идентификатор OpenID Connect Identity (OIDC) и OAuth 2.0 с подключаемым разъемом.

Ответ с этого поста vonc

Answer 3

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

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

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

При этом

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