OAuth 2.0 – хороший, плохой, злой

В мире, где доминируют социальные сети, редко возникает соблазн не установить клиентское приложение, которое может получить доступ к ограниченным ресурсам на отдельном сервере.

Например, вы можете использовать веб-приложение (такое как New York Times) для вставки интересных статей в вашу ленту Facebook или Twitter. В качестве альтернативы можно использовать приложение для iPhone под названием Quora, которое дает доступ к тем же новостным лентам Facebook или Google+.

Настраиваемая информация о профиле: добавить в / пригласить вQuora. Пользователи из списка ваших друзей. Вопрос в том, как эти приложения могут получить доступ к аккаунтам Facebook, Twitter или Google+ и, самое главное, к конфиденциальной информации.

Прежде чем приложение сможет это сделать, необходимо предоставить серверному ресурсу определенную форму аутентификации и авторизации.

Введение в OAuth 2.0

В наши дни очень полезно иметь возможность делиться постами Facebook и Google+ с помощью сторонних клиентских приложений. Сервис также ограничивает нежелательный доступ, а также отслеживает пользователей на основе имени пользователя и пароля, гарантируя, что только друзья смогут получить доступ к вашим сообщениям.

Где мы находимся.OAuth.Это система удаленного доступа/делегирования лицензий, которую можно использовать без необходимости дополнительного обмена паролями. По этой причине OAuth часто называютБрелок с обслуживающим персоналом Интернета.

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

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

Однако OAuth не основан на совершенно новой технологии, а использует разумную комбинацию стандартных, устоявшихся протоколов.

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

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

Ресурс владельца.: Приложение, которое может предоставлять доступ к защищенным ресурсам. Как правило, конечному пользователю предоставляется доступ кКлиент.Приложение, выполняющее запросы к защищенному ресурсу от имени владельца с его разрешения. Это может быть серверное приложение, мобильное приложение или настольное приложение.Ресурсный сервер.Сервер на защищенном ресурсе, который может получать и отвечать на запросы к ресурсу.Авторизация на сервере.После успешной аутентификации и авторизации у владельца ресурса сервер выдает клиенту маркер предоставления/доступа, который затем может быть использован для запросаМаркер доступа.Учетные данные доступа: учетные данные доступа (маркер доступа к учетным данным), предоставляемые клиентом серверу ресурсов для того, чтобы иметь возможность использовать защищенный ресурс. Обычно это набор параметров, определяющих ограничения доступа, продолжительность сеанса и другие атрибуты. Он также может содержать некоторые данные аутентификации.Обновление маркера.Токен доступа: Хотя он не предоставляется по умолчанию, в идеале токены доступа должны иметь время истечения срока действия (сессии) от нескольких минут до нескольких часов. Когда срок действия маркера доступа истекает, клиент может запросить у сервера авторизацию и выдачу нового маркера доступа путем обновления маркера.

Каковы проблемы с OAuth 1.0?

Главный недостаток OAuth 1.0 заключается в том, что эта версия очень сложна.

На самом деле, у нас не было никаких проблем с этим! Twitter добавил поддержку OAuth 1.0 идобавлена поддержка OAuth 1.0 и Версия 2.0. OAuth 1.0 был хорошо разработанной рамочной версией, которая обеспечивала безопасный обмен личной информацией и обмен конфиденциальной информацией без SSL-соединения.

Пришлось разработать обновленную версию, в основном из-за сложности, с которой пришлось столкнуться. Ниже перечислены некоторые области, в которых OAuth 1.0 не соответствовал современным требованиям

Подписание каждого заявления.: Пусть клиент генерирует подпись для каждого запроса приложения и проверяет каждый запрос на сервере. Это стало серьезным ударом для разработчиков, которым приходилось разбирать, кодировать и сортировать параметры перед отправкой запроса.

OAuth 2.0 успешно избегает этой сложности. Он решает эту проблему на сетевом уровне, просто отправляя маркеры по протоколу SSL. OAuth 2.0 не требует подписи.Перенаправление встроенных приложений.: При разработке встроенных приложений для мобильных браузеров веб-поток OAuth 1.0 просто неэффективен.

Поэтому необходимо использовать агента, например, сам веб-браузер. В OAuth 2.0 потоки особенно сосредоточены на работе со встроенными приложениями.Четкое разделение ролей.: OAuth 2.0 обеспечивает необходимое разделение ролей для серверов аутентификации, аутентификации и аутентификации клиентов, позволяя серверам ресурсов обрабатывать запросы приложений на доступ к частным ресурсам.

OAuth 2.0 в деталях

Перед инициализацией протокола клиент должен зарегистрироваться на сервере авторизации и указать тип клиента, URL перенаправления (куда сервер ресурсов будет перенаправлять для авторизации после предоставления или отказа в доступе) и любую другую информацию, требуемую сервером. .

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

Возможные потоки OAuth

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

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

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

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

Примерами такого взаимодействия являются устройства с широкими правами доступа или операционные системы приложений. Его также можно использовать для миграции существующих клиентов через HTTP или для аутентификации в OAuth.Поток авторизации.: клиентам могут выдаваться сертификаты, например, сертификаты SAML, в обмен на предоставленные купоны доступа.Поток идентификационных данных клиентаOAUTH: OAUTTH в основном используется для авторизованного доступа, но могут быть случаи, когда клиент также является владельцем ресурса или ему уже предоставлены права доступа, выходящие за рамки обычного потока OAuth. Речь идет об обмене идентификаторов клиентов на купоны доступа.

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

Однако для более базового понимания давайте углубимся в один из наиболее часто используемых потоков — поток веб-сервера.

Поток веб-сервера.

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

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

Аутентификация и авторизация клиентов

Клиент, от имени владельца Pollos, инициирует поток, перенаправляя в финал авторизации: идентификатор клиента, полученный при регистрации клиента в качестве кода response_type, URL перенаправления, поля, требующие авторизации (необязательно) и текущий статус (если требуется).

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

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

Когда клиент получает разрешение на доступ от владельца ресурса, сервер авторизации перенаправляет пользователя к клиенту с помощью кода авторизации, используя ранее предоставленные параметры перемещения.

Это показано на следующей диаграмме

Происходит обмен токеном и кодом авторизации

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

Сервер проверяет код авторизации, как и на предыдущем этапе, и перенаправляет URL. В случае успеха сервер отвечает перехватом доступа и, опционально, UP -Date to Date Discreet.

Применение доступа к ограниченным ресурсам с использованием знаков отличия Access Insignia.

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

В данном случае под заголовкомРазрешено. Заголовок заявления прилагается к отвлечению "Доступ". В качестве примера, Curl-запрос для получения данных из API Google Blogger, включая идентификационные данные, может содержать следующий код.

$ curl https://www.googleapis.com/blogger/v3/blogs/5223788876950011016 -h 'Аутентификация: oauth ya29.aes6zrtj1gnxaby81es -p_ypwnbafrvbyvsyj2hzjfju

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

Обратите внимание, что маркировка отвлекающих факторов доступа требуется только для двух коммуникаций. Это позволяет отправить запрос.

Затем сервер ресурсов проверяет отправленные данные (доступ) и, в случае успеха, отправляет запрошенную информацию.

Эти примеры показывают, как это делаетсяИгровая площадка OAuth2.0.. Вот как эта версия обычно взаимодействует с Google.

Доступ к другим сервисам (например, Facebook или Salesforce) может привести к несколько иному взаимодействию, в зависимости от их совместимости с конечным решением. Это объясняется далее в этом разделе.

Обновление уникального доступа.

Хотя это не предусмотрено по умолчанию, купоны доступа обычно имеют ограниченный срок действия. Поэтому, когда срок действия токена истекает, клиент отправляет запрос на сервер авторизации для обновления токена.

Это сопровождается идентификатором клиента, секретным кодом и параметром grant_type refresh_token.

В ответ сервер авторизации отправляет новый пакет с ценой купона.

Существует механизм отзыва маркера Up -to -Date, который обычно хранится вечно и должен быть защищен, как и все секретные данные.

Так в чем же заключаются проблемы с OAUTH 2.0?

Хорошо (положительные моменты).

Судя по скорости, с которой был выпущен OAUTH 2.0, он определенно является шагом вперед по сравнению со своим предшественником. Хорошо известно, что члены сообщества разработчиков столкнулись с трудностями при внедрении версии 1.0. Хотя OAUTH 2.0 предоставляет различные новые типы грантов, которые могут быть использованы для реализации различных пользовательских задач, связанных с построенным приложением, основным преимуществом этой версии фрейма является его простота по сравнению с версией 1.0.

Хуже (отрицательные баллы).

Необработанные элементы OAuth 2.0 могут привести к ряду взаимно несовместимых решений по реализации.

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

Взаимодействие.: Добавление слишком большого количества обновлений и расширений сделало некоторые элементы несовместимыми друг с другом. Это означает, что вы не можете использовать Endpoint Discovery для написания типового кода и убедиться, что он подходит для всех различных служб.

Фактически, вам нужно создать отдельный код для Facebook, Google, Salesforce и т.д.Этот пункт Хотя спецификация релиза признаетОграничения по срокам действия ваучеров.: Данная версия системы не обеспечивает неограниченный срок действия всех выданных ваучеров.

Однако, в зависимости от конкретного практического решения, это может быть возможно. Однако в большинстве случаев предоставляются краткосрочные жетоны доступа, которые можно продлить по запросу.Безопасность.: Эта версия "Рекомендуется."Используйте SSL/TLS, если токены отправляются по сети в виде обычного текста.

Основное решение должно иметь безопасную конечную точку авторизации, но должно иметь безопасный URL перенаправления для клиента. В противном случае злоумышленнику будет очень легко перехватить сообщения и расшифровать токены.

Зло…

Около 31 черновика концепции были перепроверены, а ведущий автор/разработчик Эран Хаммер также был отстранен от работы.Новая версия …наконец-то увидел свет. Эран настаивал на том, что спецификация применима".Это был плохой протокол и нежизнеспособный из-за тысячи других недостатков.».

По его словам, использование брендаперевозчиквместо подписей пользователей (или MAC-токенов), используемых в OAuth 1.0 (отправка токенов через SSL без подписи или другой проверки) является плохим решением. Онлайн-сообщество.

Несколько замечаний в заключение

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

Это не гарантирует, что практические решения от разных поставщиков будут успешно работать вместе.

Однако с каждым новым внедрением крупных сервисов (Google, Twitter, Facebook, Salesforce, Foursquare, Github и т.д.) OAuth становится все более популярным.

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