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

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

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

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

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

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

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

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

Предыстория: я написал клиентские и серверные стеки для 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), которые сейчас широко используются.

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

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

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

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

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

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

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

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

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

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

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

Тем самым,

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