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

OAuth 2․0 – это протокол авторизации‚ который широко используется в современной веб-разработке для обеспечения безопасного взаимодействия между клиентскими приложениями и защищенными ресурсами․ Он предоставляет стандартные методы авторизации через открытый API и широко применяется в различных сервисах‚ включая социальные сети‚ облачные платформы‚ а также во внутренних корпоративных системах․

Преимущества OAuth 2․0

OAuth 2․0 предлагает несколько значительных преимуществ⁚

• Гибкость⁚ протокол позволяет клиентским приложениям запрашивать доступ к защищенным ресурсам от имени пользователя․
• Простота использования⁚ OAuth 2․0 является относительно простым для реализации и использования благодаря широкой поддержке различных языков программирования и фреймворков․
• Безопасность⁚ протокол обеспечивает безопасность защищенных ресурсов‚ поскольку не требует передачи логина и пароля от пользователя․

Недостатки OAuth 2․0

Вместе с преимуществами‚ у OAuth 2․0 есть и недостатки⁚

• Сложность настройки⁚ неправильная конфигурация может привести к уязвимостям в системе‚ поэтому требуется следовать наилучшим практикам при использовании протокола․
• Возможные угрозы безопасности⁚ некорректная реализация OAuth 2․0 может привести к утечкам данных и другим серьезным уязвимостям․
• Неоднозначность спецификации⁚ некоторые аспекты протокола могут толковаться по-разному разработчиками‚ что может привести к проблемам в совместимости между различными системами․

OAuth 2․0⁚ будущее и современные тренды

В настоящее время OAuth 2․0 активно развивается‚ появляются новые версии спецификаций и дополнения‚ которые направлены на устранение недостатков и улучшение безопасности․ С развитием цифровой экономики и множеством устройств‚ использующих веб-сервисы‚ применение OAuth 2․0 становится все более востребованным․

Хотя OAuth 2․0 имеет свои недостатки‚ он остается важным инструментом в сфере веб-разработки и обеспечивает удобство и безопасность при взаимодействии с защищенными ресурсами․ Однако внимательная настройка и строгое соблюдение рекомендаций по использованию протокола являются важными аспектами для обеспечения безопасности веб-приложений и защиты конфиденциальной информации пользователей․

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

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

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

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

Интерпретация OAuth 2.0

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

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

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

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

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

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

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

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

В чем заключалась проблема с OAuth 1.0?

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

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

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

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

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

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

OAuth 2.0 подробно

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

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

Возможности OAuth

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

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

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

Примером клиента для этого типа взаимодействия может быть операционная система на устройстве или приложение с детализированными разрешениями. Его также можно использовать для миграции существующих клиентов, использующих схемы аутентификации HTTP или Digest, на OAuth путем преобразования зарегистрированных учетных данных в токен доступа; FlowУтверждения : ваш клиент может предоставить одобрение, например одобрение SAML, в обмен на предоставленный токен доступа; Customer Identity Flow : OAuth в основном используется для делегированного доступа, но в некоторых случаях когда клиент также владеет ресурсом или ему были предоставлены права доступа, выходящие за рамки обычного потока. Это просто замена идентификатора клиента токеном доступа.

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

 

Но Чтобы дать вам больше знаний о них, давайте подробнее рассмотрим один из наиболее часто используемых потоков: поток веб-сервера.

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

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

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

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

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

Заголовок запроса Authorization содержит токен доступа. Пример запроса CURL для получения учетных данных от Google Blogger API для вашего блога:

 $ curl https://www.googleapis.com/blogger/v3/blogs/5223788876950011016 -H 'Авторизация: OAuth ya29. AHES6ZRTj1GNxAby81Es-p_YPWWNBAFRvBYVsYj2HZJfJHU '

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

доступ требуется только для двоих двустороннее общение. В результате отправляется запрос:

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

Примеры выше показывают, как OAuth2.0 Playground . Обычно мы делаем это путем взаимодействия с Google.

Взаимодействие может немного отличаться при доступе к другим службам (например, Facebook или Salesforce) из-за проблем совместимости между окончательными решениями, которые мы обсудим позже.

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

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

Включает идентификатор клиента и секретный код, а также параметр grant_type как refresh_token.

Сервер авторизации отвечает отправкой пакета с новым значением токена.

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

Так в чем проблема с OAuth 2.0?

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

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

Плохо (отрицательные).

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

В этом выпуске все еще есть несколько слабых мест из-за того, что некоторые из требуемых компонентов не могут быть определены правильно или взаимодействия с ними еще не определены:

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

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

Однако, в зависимости от конкретных практических решений, такие возможность существует. Однако в большинстве случаев предоставляется краткосрочный токен доступа с возможностью его продления по запросу; Безопасность : эта версия только « рекомендует » использовать SSL/TLS. при отправке токенов в виде обычного текста по сети.

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

Evil …

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

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

Несколько заключительных замечаний

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

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

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

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