OAuth и OAuth 2: использование данных на разных платформах

В наши дни мы используем множество веб-сайтов, программ и мобильных приложений, чтобы сделать нашу личную и профессиональную жизнь проще или комфортнее. При таком широком разнообразии инструментов для многих людей стало нормой пользоваться таким приложением, как Instagram, на другом сайте, например, Facebook. Другими словами, можно работать на разных платформах. Однако, поскольку в ходе этих процессов передается большое количество персональных данных, имеет смысл задаться вопросом о безопасности этой передачи. Протокол авторизации OAuth разработан для снижения риска несанкционированного использования данных — наш вопрос в том, сможет ли он справиться с этой весомой задачей?

Объяснение OAuth

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

Это означает, что если, например, приложение должно публиковать данные в Facebook от имени пользователя (т.е. обращаться к API Facebook), оно должно иметь разрешение от этого пользователя. Аналогичным образом, приложению нужны полномочия пользователя для извлечения информации о его профиле из другого сервиса. Благодаря OAuth пользователь может дать такое разрешение без необходимости сообщать авторизованному приложению свое имя пользователя и пароль — другими словами, он сохраняет полный контроль над своими данными.

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

Какие изменения произошли в OAuth2?

OAuth2 (также называемый «OAuth 2.0») был опубликован в октябре 2012 года как полный пересмотр OAuth и в настоящее время в значительной степени заменил его. Graph API Facebook поддерживает только новый протокол в качестве стандарта авторизации. В качестве основы для него служит уровень аутентификации OpenID Connect (OIDC).

В принципе, задача OAuth2 та же, что и у его предшественника — предоставление пользователю большей гибкости и одновременно высокой безопасности посредством авторизации API. Однако были исправлены многочисленные недостатки оригинального протокола, что усложнило кодирование и внедрение по мере того, как системы Facebook, Twitter и других операторов API со временем становились все сложнее.

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

В Open Authorization 2.0 также были добавлены более дифференцированные типы грантов и улучшена производительность протокола. Разработчики добились этого за счет того, что OAuth2 больше не запрашивает данные доступа пользователя (владельца ресурса) на каждом шаге взаимодействия, а только при первичной авторизации соответствующего приложения (клиента). Другим заметным нововведением являются токены доступа с более коротким сроком действия, что облегчает сервису (серверу ресурсов) отзыв авторизации. Кроме того, в рамках OAuth2 пользователь может решать, какие полномочия (область действия) он предоставляет приложению.

Различия между OpenID, SAML и OAuth

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

OpenID против OAuth 2.0

OpenID (сокращение от «открытая идентификация») — это, как следует из названия, открытый протокол. Когда пользователь создает учетную запись OpenID, он может использовать ее для входа в другие сервисы и приложения, которые также поддерживают OpenID, с помощью маркера. Хорошим примером этого является функция «зарегистрироваться в Google», которую сегодня можно найти на многих веб-сайтах и которая позволяет осуществлять единую процедуру входа в систему через учетную запись Google пользователя.

В отличие от OAuth, OpenID, строго говоря, является не авторизацией, а процедурой аутентификации. Эти две процедуры тесно связаны между собой с 2014 года: OAuth 2.0 — это основа, на которой построена новая версия OpenID, получившая название OpenID Connect (OIDC). OAuth2 позволяет различным типам приложений (клиентов) проверять личность пользователя через аутентификацию сервером авторизации — и получать дополнительную базовую информацию о нем. Взамен добавляются все необходимые функции для входа в систему и единой регистрации. OpenID Connect также может быть расширен дополнительными функциями, такими как управление сессиями и шифрование идентификационных данных.

SAML против OAuth 2.0

Открытый и основанный на XML «Security Assertion Markup Language» (сокращенно: SAML) сочетает в себе свойства двух предыдущих концепций. Он является стандартом как для аутентификации, так и для авторизации. По своей функциональности SAML схож с OpenID и также используется для процедур единой регистрации.

Функциональные возможности OAuth2

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

Роли в OAuth2

OAuth2 определяет четыре роли:

  • Владелец ресурса (также: пользователь): Организация, предоставляющая клиенту доступ к своим защищенным данным (также: ресурсы).
  • Сервер ресурса (также: сервис): Сервер, на котором хранятся защищенные данные владельца ресурса.
  • Клиент (также: третья сторона): Настольное, веб- или мобильное приложение, которое хочет получить доступ к защищенным данным владельца ресурса.
  • Сервер авторизации: Сервер, который проверяет подлинность владельца ресурса и выдает временный маркер доступа для области, определенной владельцем ресурса. На практике сервер авторизации и сервер ресурсов часто работают вместе и тогда их также называют OAuth Server.

Типы грантов в OAuth2

Кроме того, различают четыре предопределенных процесса авторизации (типы грантов), которые используются в различных приложениях:

  • Код авторизации: Клиент просит владельца ресурса войти на сервер авторизации. Затем владелец ресурса перенаправляется к клиенту вместе с кодом авторизации. В обмен на этот код сервер авторизации выдает клиенту маркер доступа.
  • Неявная авторизация: Этот процесс утверждения очень похож на авторизацию по коду авторизации, но менее сложен, поскольку сервер авторизации выдает маркер доступа напрямую.
  • Учетные данные пароля владельца ресурса: Здесь владелец ресурса доверяет свои данные доступа непосредственно клиенту, что во многом противоречит основному принципу OAuth, но означает меньше усилий для владельца ресурса.
  • Учетные данные клиента: Этот очень простой процесс утверждения используется, когда клиент хочет получить доступ к данным, которые не имеют владельца или не требуют авторизации.

Пример процесса обобщенного протокола OAuth2

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

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

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

Конкретный пример OAuth

Социальные сети Pinterest и Facebook представляют конкретные примеры процедуры OAuth2. Pinterest предлагает возможность импортировать контакты из списков друзей Facebook. Для этого Pinterest необходим доступ к соответствующей учетной записи и хранящейся в ней информации. Однако по соображениям безопасности данных передавать имя пользователя и пароль из Facebook в Pinterest неразумно — ведь тогда Pinterest получит неограниченный доступ ко всем данным и функциям аккаунта Facebook в любое время. Для того чтобы Pinterest все же смог получить доступ к необходимым данным Facebook, используется протокол OAuth2:

  1. Сначала вы входите в свой аккаунт Pinterest и переходите к настройкам в профиле пользователя.
  2. В строке меню «социальные сети» переместите ползунок рядом с «Facebook» на «да».
  3. Теперь Pinterest просит вас войти в Facebook и подтвердить приложение Pinterest. Это действие считается авторизацией.
  4. Pinterest запрашивает маркер доступа у сервера авторизации Facebook, а затем использует его для доступа к защищенным данным на сервере ресурсов.
  5. Импортированные друзья Facebook теперь также отображаются в аккаунте Pinterest.

Безопасность и критика OAuth и 2.0

Тот факт, что даже такая система, предназначенная для защиты персональных данных, как OAuth, не может быть на сто процентов совершенной, уже был продемонстрирован в апреле 2009 года, когда в процессе аутентификации была обнаружена брешь в системе безопасности. Как и для многих других подобных систем, фишинг также является постоянным риском, и в период с апреля по май 2017 года один миллион пользователей Gmail стал жертвой фишинговой атаки на основе OAuth. В мошенническом электронном письме пользователям предлагалось авторизовать поддельный интерфейс, чтобы якобы приложение под названием «Google Apps» получило доступ к данным их аккаунта.

В октябре 2012 года усилия по повышению безопасности OAuth в его новой модели, OAuth 2, достигли окончательного результата — но без одобрения первоначальных разработчиков. Только главный редактор OAuth2 Эран Хаммер-Лахав работал над старым OAuth — и даже он в итоге дистанцировался от нового проекта за три месяца до его выхода. В статье на своем блоге hueniverse.com от 26 июля 2012 года он объяснил причину своего решения и назвал OAuth 2.0 «дорогой в ад» в заголовке.

Что же произошло? По словам Хаммера-Лахава, развитие нового протокола определялось постоянными дебатами между разработчиками и вовлеченными компаниями (включая Yahoo!, Google, Twitter и Deutsche Bank). В какой-то момент вопросы были проигнорированы в пользу экономических интересов. Следствием этого стала программа, которую, по словам Хаммера-Лахава, уже нельзя было назвать безопасной. Вместо того чтобы представлять собой точный стандартизированный протокол, OAuth2 — это, по сути, основа, которую можно адаптировать и расширять по своему усмотрению.

Еще одна вещь, о которой сожалеет Хаммер-Лахав, это тот факт, что было принято решение реализовать OAuth 2.0 более просто (например, опустив подписи), что приводит к отсутствию безопасности. Для того чтобы запрограммировать безопасное приложение, поддерживающее OAuth2, разработчики должны обладать значительным опытом. Поэтому более вероятно, что в будущем в сети будут накапливаться небезопасные приложения. Ошибки в реализации неизбежны, учитывая неполноту и чрезмерную сложность спецификаций, говорит Хаммер-Лахав.

Хаммер-Лахав отчасти прав в своих опасениях. В 2016 году исследовательская группа Трирского университета столкнулась с проблемой безопасности OAuth2 и обнаружила две бреши в защите. Одна из них позволяла проводить атаки типа «человек посередине». Однако в целом исследователи сочли протокол относительно безопасным — при условии его правильной реализации.

Оцените статью
cdelat.ru
Добавить комментарий