Содержание

OAuth 2.0 простым и понятным языком / Хабр

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

Что такое OAuth 2.0

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

Чем отличаются OpenID и OAuth

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

OpenID предназначен для аутентификации — то есть для того, чтобы понять, что этот конкретный пользователь является тем, кем представляется. Например, с помощью OpenID некий сервис Ололо может понять, что зашедший туда пользователь, это именно Рома Новиков с Mail. Ru. При следующей аутентификации Ололо сможет его опять узнать и понять, что, это тот же Рома, что и в прошлый раз.

OAuth же является протоколом авторизации, то есть позволяет выдать права на действия, которые сам Ололо сможет производить в Mail.Ru от лица Ромы. При этом Рома после авторизации может вообще не участвовать в процессе выполнения действий, например, Ололо сможет самостоятельно заливать фотографии на Ромин аккаунт.

Как работает OAuth 2.0

Как и первая версия, OAuth 2.0 основан на использовании базовых веб-технологий: HTTP-запросах, редиректах и т. п. Поэтому использование OAuth возможно на любой платформе с доступом к интернету и браузеру: на сайтах, в мобильных и desktop-приложениях, плагинах для браузеров…

Ключевое отличие от OAuth 1.0 — простота. В новой версии нет громоздких схем подписи, сокращено количество запросов, необходимых для авторизации.

Общая схема работы приложения, использующего OAuth, такова:

  1. получение авторизации
  2. обращение к защищенным ресурсам

Результатом авторизации является access token — некий ключ (обычно просто набор символов), предъявление которого является пропуском к защищенным ресурсам.

Обращение к ним в самом простом случае происходит по HTTPS с указанием в заголовках или в качестве одного из параметров полученного access token‘а.

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

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


  1. Редирект на страницу авторизации
  2. На странице авторизации у пользователя запрашивается подтверждение выдачи прав
  3. В случае согласия пользователя, браузер редиректится на URL, указанный при открытии страницы авторизации, с добавлением в GET-параметры специального ключа — authorization code
  4. Сервер приложения выполняет POST-запрос с полученным authorization code в качестве параметра. В результате этого запроса возвращается
    access token

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

Пример

Здесь и далее примеры приводятся для API Mail.Ru, но логика одинаковая для всех сервисов, меняются только адреса страниц авторизации. Обратите внимание, что

запросы надо делать по HTTPS.

Редиректим браузер пользователя на страницу авторизации:

> GET /oauth/authorize?response_type=code&client_id=464119&
      redirect_uri=http%3A%2F%2Fexample.com%2Fcb%2F123 HTTP/1. 1
> Host: connect.mail.ru

Здесь и далее, client_id и client_secret — значения, полученные при регистрации приложения на платформе.

После того, как пользователь выдаст права, происходит редирект на указанный redirect_uri:

< HTTP/1.1 302 Found
< Location: http://example.com/cb/123?code=DoRieb0y

Обратите внимание, если вы реализуете логин на сайте с помощью OAuth, то рекомендуется в redirect_uri добавлять уникальный для каждого пользователя идентификатор для предотвращения CSRF-атак (в примере это 123). При получении кода надо проверить, что этот идентификатор не изменился и соответствует текущему пользователю.

Используем полученный code для получения access_token, выполняя запрос с сервера:

> POST /oauth/token HTTP/1.1
> Host: connect.mail.ru
> Content-Type: application/x-www-form-urlencoded
> 
> grant_type=authorization_code&client_id=464119&client_secret=deadbeef&code=DoRieb0y&
  redirect_uri=http%3A%2F%2Fexample.
 
 com%2Fcb%2F123
< HTTP/1.1 200 OK
< Content-Type: application/json
<
< {
<    "access_token":"SlAV32hkKG",
<    "token_type":"bearer",
<    "expires_in":86400,
<    "refresh_token":"8xLOxBtZp8",
< }

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

В результате последнего запроса получаем сам ключ доступа (access_token), время его «протухания&raquo (expires_in), тип ключа, определяющий как его надо использовать, (token_type) и refresh_token о котором будет подробнее сказано ниже. Дальше, полученные данные можно использовать для доступа к защищенным ресурсам, например, API Mail.Ru:

> GET /platform/api?oauth_token=SlAV32hkKG&client_id=464119&format=json&method=users.getInfo&
      sig=... HTTP/1.1
> Host: appsmail.ru

Описание в спецификации

Авторизация полностью клиентских приложений


  1. Открытие встроенного браузера со страницей авторизации
  2. У пользователя запрашивается подтверждение выдачи прав
  3. В случае согласия пользователя, браузер редиректится на страницу-заглушку во фрагменте (после #) URL которой добавляется access token
  4. Приложение перехватывает редирект и получает access token из адреса страницы

Этот вариант требует поднятия в приложении окна браузера, но не требует серверной части и дополнительного вызова сервер-сервер для обмена authorization code на access token.

Пример

Открываем браузер со страницей авторизации:

> GET /oauth/authorize?response_type=token&client_id=464119 HTTP/1.1
> Host: connect.mail.ru

После того, как пользователь выдаст права, происходит редирект на стандартную страницу-заглушку, для Mail.Ru это

connect.mail.ru/oauth/success.html:

< HTTP/1.1 302 Found
< Location: http://connect.mail.ru/oauth/success.html#access_token=FJQbwq9&token_type=bearer&
            expires_in=86400&refresh_token=yaeFa0gu

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

Описание в спецификации

Авторизация по логину и паролю

Авторизация по логину и паролю представляет простой POST-запрос, в результате которого возвращается access token. Такая схема не представляет из себя ничего нового, но вставлена в стандарт для общности и рекомендуется к применению только, когда другие варианты авторизации не доступны.

Пример
> POST /oauth/token HTTP/1.1
> Host: connect.mail.ru
> Content-Type: application/x-www-form-urlencoded
> 
> grant_type=password&client_id=31337&client_secret=deadbeef&[email protected]&
  password=qwerty
< HTTP/1.1 200 OK
< Content-Type: application/json
<
< {
<    "access_token":"SlAV32hkKG",
<    "token_type":"bearer",
<    "expires_in":86400,
<    "refresh_token":"8xLOxBtZp8",
< }

Описание в спецификации

Восстановление предыдущей авторизации

Обычно, access token имеет ограниченный срок годности. Это может быть полезно, например, если он передается по открытым каналам. Чтобы не заставлять пользователя проходить авторизацию после истечения срока действия access token‘а, во всех перечисленных выше вариантах, в дополнение к access token‘у может возвращаться еще refresh token. По нему можно получить access token с помощью HTTP-запроса, аналогично авторизации по логину и паролю.

Пример
> POST /oauth/token HTTP/1.1
> Host: connect.mail.ru
> Content-Type: application/x-www-form-urlencoded
> 
> grant_type=refresh_token&client_id=31337&client_secret=deadbeef&refresh_token=8xLOxBtZp8
< HTTP/1.1 200 OK
< Content-Type: application/json
<
< {
<    "access_token":"Uu8oor1i",
<    "token_type":"bearer",
<    "expires_in":86400,
<    "refresh_token":"ohWo1ohr",
< }

Описание в спецификации

Минусы OAuth 2.0

Во всей этой красоте есть и ложка дегтя, куда без нее?

OAuth 2.0 — развивающийся стандарт. Это значит, что спецификация еще не устоялась и постоянно меняется, иногда довольно заметно. Так, что если вы решили поддержать стандарт прямо сейчас, приготовьтесь к тому, что его поддержку придется подпиливать по мере изменения спецификации. С другой стороны, это также значит, что вы можете поучаствовать в процессе написания стандарта и внести в него свои идеи.

Безопасность OAuth 2.0 во многом основана на SSL. Это сильно упрощает жизнь разработчикам, но требует дополнительных вычислительных ресурсов и администрирования. Это может быть существенным вопросом в высоко нагруженных проектах.

Заключение

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

Со своей стороны, мы внедрили OAuth 2.0 в API Mail.Ru и, теперь, вы можете использовать возможности протокола для реализации любых клиентов и сервисов, интегрированных с Mail.Ru.

Ссылки


  • Текущая версия драфта стандарта OAuth 2.0
  • Официальный сайт OAuth
  • Рабочая группа по выработке стандарта (архивы)
  • Документация по реализации OAuth 2. 0 в Mail.Ru

Дмитрий Битман — менеджер Платформы@Mail.Ru

Протокол авторизации OAuth 2 — введение в технологию на примерах

В статье рассмотрим механику, способы и примеры использования технологии.

Что такое OAuth 2 — обзор

OAuth 2 — это протокол авторизации, предназначенный для организации доступа клиентских приложений к ресурсам, или данным учетных записей, пользователя на другом сервисе. В качестве клиентских приложений выступают веб-сервисы, мобильные и десктопные приложения. В качестве сервисов — mail.ru, GitHub, Bitbucket и др. Протокол используют разработчики сторонних приложений. 

Мы сталкиваемся с этим протоколом, когда:

  • авторизуемся на сторонних площадках через аккаунты соцсетей;
  • устанавливаем себе на мобильное устройство приложение, взаимодействующее с нашими данными в облачных сервисах типа Google или Яндекс;
  • используем сторонние приложения (боты в Telegram и других мессенджерах) для уведомлений и пр.

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

Различия протоколов OpenID и OAuth 2

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

Для верификации пользователя OpenID использует ID учетной записи у провайдера, а OAuth — авторизационные ключи (токены) с предопределенным сроком действия и правами доступа.

Используемые роли в OAuth 2

В рамках описываемого протокола выделяются следующие типы ролей:

  • владелец (пользователь): авторизует клиентское приложение на доступ к данным своего аккаунта;
  • сервер ресурсов/API: здесь располагаются данные пользовательских аккаунтов, а также бизнес-логика авторизации, отвечающая за выдачу новых OAuth-токенов и проверку их подлинности при обращении клиентских приложений к ресурсам. Целесообразно объединять эти роли, так как физически это один сервис;
  • клиентское приложение: собственно сервис, которому пользователь делегирует права доступа к своим данным на сервере ресурсов. Пользователь должен авторизовать приложение, а со стороны сервера API оно должно получить подтверждение в виде ключа (токена) доступа. 

Как работает OAuth 2: от запроса на авторизацию до генерации токена

Рассмотрим схему, описывающую принцип действия протокола.

Выделим следующие шаги:

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

В зависимости от бизнес-логики клиентского приложения последовательность шагов может меняться. Далее рассмотрим наиболее распространенные примеры использования OAuth 2.

Регистрация приложения на сервере API

Вне зависимости от того, с каким именно сервисом выполняется интеграция вашего приложения, его необходимо в первую очередь зарегистрировать. Делается это с помощью специального портала на сайте сервиса, с которым выполняется интеграция (например, https://console. cloud.google.com для Google). 

Заполните все необходимые сведения о приложении:

  • тип,
  • используемые сервисы,
  • название,
  • информация о разработчике и пр.

Также в зависимости от архитектуры приложения, возможно, потребуется предоставить callback или redirect url — адрес, на который ваше приложение будет перенаправлять пользователя после успешной авторизации или же отказа от нее. 

На финальном этапе вам будут предоставлены два строковых ключа: client_id (ID клиента) и client_secret (секрет клиента). Первый служит для идентификации приложения, а также генерации авторизационных URL для пользователей — параметр является публичным. Секрет же предназначен для проверки подлинности приложения API сервисом в тот момент, когда оно запрашивает доступ к пользовательскому аккаунту. Секрет должен быть известен только приложению и API.

OAuth для приложений с серверной частью: рассмотрим по шагам

Последовательность шагов приведена на схеме ниже.

  1. Пользователь перенаправляется на страницу авторизации, где у него запрашиваются разрешения для приложения на работу с данными его аккаунта.
  2. После предоставления необходимых разрешений пользователь попадает на callback URL — адрес, указанный при регистрации приложения, предназначенный для завершения авторизации. При этом происходит подстановка кода авторизации в  GET-параметры адреса.
  3. Сервер клиентского приложения формирует POST-запрос к серверу авторизации API с кодом авторизации в качестве параметра.
  4. Сервер авторизации проверяет код и возвращает приложению токен доступа (access token).
  5. Используя токен, приложение авторизуется на сервере API и получает доступ к запрашиваемым пользовательским ресурсам.

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

Пример реализации использования протокола

У нас есть приложение с серверной частью, использующее API mail.ru.

Перенаправим пользователя на страницу авторизации.

> GET /oauth/authorize?response_type=code&client_id=464119&
      redirect_uri=http%3A%2F%2Fexample.com%2Fcb%2F123 HTTP/1.1
> Host: connect.mail.ru

Значения параметров ID клиента (client_id), секрета клиента (client_secret) и URL страницы подтверждения авторизации (redirect_uri) разработчик получает при регистрации своего приложения на платформе.

Когда пользователь предоставит приложению разрешение на доступ к своему аккаунту, он будет перенаправлен на redirect_uri:

< HTTP/1.1 302 Found
< Location: http://example.com/cb/123?code=DoRieb0y

Рекомендуем в redirect_uri добавлять уникальный идентификатор пользователя для предотвращения CSRF-атак (в приведенном примере это 123). При получении кода авторизации необходимо проверить подлинность идентификатора и его соответствие текущему пользователю. 

Далее необходимо обменять код авторизации на ключ доступа (токен):

> POST /oauth/token HTTP/1.1
> Host: connect.mail.ru
> Content-Type: application/x-www-form-urlencoded
> 
> grant_type=authorization_code&client_id=464119&client_secret=deadbeef&code=DoRieb0y&
  redirect_uri=http%3A%2F%2Fexample.com%2Fcb%2F123
< HTTP/1.1 200 OK
< Content-Type: application/json
<
< {
<    "access_token":"SlAV32hkKG",
<    "token_type":"bearer",
<    "expires_in":86400,
<    "refresh_token":"8xLOxBtZp8",
< }

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

В результате сервер API возвращает токен доступа (access_token), его тип (token_type), срок жизни (expires_in), а также ключ для обновления токена (refresh_token). Полученные данные можно использовать для работы с пользовательским аккаунтом через API:

> GET /platform/api?oauth_token=SlAV32hkKG&client_id=464119&format=json&method=users.getInfo&
      sig=... HTTP/1.1
> Host: appsmail.ru

OAuth для полностью клиентских приложений

Стороннее приложение может представлять собой лишь графический интерфейс без серверной бизнес-логики и выполнять взаимодействие с сервисом API с помощью кода на клиенте — например, мобильное приложение календаря, заметок и т.д.

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

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

При таком подходе опускается обмен кода авторизации на токен доступа во время обмена запросами между серверами приложения и API. Вся авторизация, как было отмечено ранее, происходит на стороне клиента.

Пример авторизации для приложения только с клиентской частью

У нас есть приложение только с клиентской частью, взаимодействующее по API с сервисами Mail.Ru. Рассмотрим процесс авторизации.

Сначала выполним переход на страницу авторизации:

> GET /oauth/authorize?response_type=token&client_id=464119 HTTP/1.1
> Host: connect.mail.ru

После подтверждения делегирования прав произойдет редирект на страницу-заглушку:

< HTTP/1.1 302 Found
< Location: http://connect.mail.ru/oauth/success.html#access_token=FJQbwq9&token_type=bearer&
            expires_in=86400&refresh_token=yaeFa0gu

Авторизуемое приложение должно зафиксировать последний редирект и изъять из параметров URL необходимые данные для доступа к сервису по API.

Авторизация по логину и паролю

Если ни один из вышеприведенных вариантов недоступен, можно использовать данный метод. Он основан на простом POST-запросе, в котором пользователь предоставляет свои учетные данные. В ответе на запрос при прохождении проверки подлинности приходят данные для работы по API.

Пример: имеется некоторое стороннее приложение, работающее с сервисами Mail.Ru по API. При этом в нем применена базовая авторизация.

Отправим запрос с нашими учетными данными и получим данные для вызова API:

> POST /oauth/token HTTP/1.1
> Host: connect.mail.ru
> Content-Type: application/x-www-form-urlencoded
> 
> grant_type=password&client_id=31337&client_secret=deadbeef&[email protected]&
  password=qwerty
< HTTP/1.1 200 OK
< Content-Type: application/json
<
< {
<    "access_token":"SlAV32hkKG",
<    "token_type":"bearer",
<    "expires_in":86400,
<    "refresh_token":"8xLOxBtZp8",
< }

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

Пример: https://oauth.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET.

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

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

Пример HTTP-запроса:

> POST /oauth/token HTTP/1.1
> Host: connect.mail.ru
> Content-Type: application/x-www-form-urlencoded
> 
> grant_type=refresh_token&client_id=31337&client_secret=deadbeef&refresh_token=8xLOxBtZp8
< HTTP/1.1 200 OK
< Content-Type: application/json
<
< {
<    "access_token":"Uu8oor1i",
<    "token_type":"bearer",
<    "expires_in":86400,
<    "refresh_token":"ohWo1ohr",
< }

Преимущества и недостатки OAuth 2

Рассмотрим подробнее плюсы и минусы протокола авторизации.

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

Минусы
  • различия в подходах к реализации у разных сервисов, порождающие необходимость написания отдельного кода под каждый новый сервис;
  • если реализована интеграция с семейством приложений, работающих в одной экосистеме (например, Google), существует риск для всех интеграций при компрометации учетных данных либо сбое на стороне сервера API;
  • OAuth 2.0 является новым и динамично развивающимся протоколом, в связи с чем возможны некоторые логические противоречия в его спецификации;
  • основанная на SSL безопасность протокола может стать проблемой в высоконагруженных проектах.

Пример реализации протокола на PHP

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

После регистрации приложения на console.developers.google.com получим файл учетных данных и сохраним его на диске сервера:

Также сохраним файл с информацией о проекте и авторизационными данными:

Установим библиотеку GoogleApiClient для PHP и подготовим код:

Код приведенного класса устанавливает соединение с сервисом API Google Таблиц, используя учетные данные в файле (credentials.json), и обменивает их на токен авторизации, с помощью которого выполняет обращение к содержимому конкретной таблицы (аргументы $sheetRange и $spreadSheetId). При этом реализована проверка жизнеспособности токена для последующих вызовов (метод checkTokenExpired). Полученный токен записывается в файл token.json и доступен для последующих вызовов API через библиотеку:

Далее используем полученный класс для обращения к данным внутри кода проекта:

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

Таким образом, OAuth 2 предоставляет гибкие возможности для быстрой интеграции с внешними сервисами.

Заключение

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

Автор текста: Роман Андреев.

Что такое OAuth? Определение и принцип работы

Блог о внутренней безопасности / Безопасность данных

Роб Соберс

|

5 минут чтения

|

Последнее обновление 5 апреля 2012 г.

Содержание

    Мы говорили о разглашении ваших паролей и о том, что вы никогда не должны этого делать. Когда веб-сайт хочет использовать услуги другого — например, Bitly для публикации в вашей ленте Twitter — вместо того, чтобы просить вас поделиться своим паролем, он должен вместо этого использовать протокол под названием OAuth.

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

    Что такое OAuth?

    OAuth — это протокол или инфраструктура авторизации открытого стандарта, которая предоставляет приложениям возможность «безопасного назначенного доступа». Например, вы можете сообщить Facebook, что ESPN. com может получать доступ к вашему профилю или публиковать обновления в вашей хронике, не сообщая ESPN свой пароль Facebook. Это значительно снижает риск: в случае взлома ESPN ваш пароль Facebook останется в безопасности.

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

    SAML и OAuth

    SAML (язык разметки подтверждения безопасности) — это альтернативный стандарт федеративной проверки подлинности, который многие предприятия используют для единого входа (SSO). SAML позволяет предприятиям отслеживать, кто имеет доступ к корпоративным ресурсам.

    Существует много различий между SAML и OAuth. SAML использует XML для передачи сообщений, а OAuth использует JSON. OAuth упрощает работу с мобильными устройствами, а SAML ориентирован на корпоративную безопасность. Этот последний пункт является ключевым отличием: OAuth широко использует вызовы API, поэтому мобильные приложения, современные веб-приложения, игровые консоли и устройства Интернета вещей (IoT) считают OAuth более удобным для пользователя. SAML, с другой стороны, размещает в браузере файл cookie сеанса, который позволяет пользователю получить доступ к определенным веб-страницам — отлично подходит для недолгих рабочих дней, но не так хорош, когда приходится каждый день входить в свой термостат.

    Beyond SSO: Singular Security от Varonis

    Oauth/SAML помогает определить, кто имеет доступ к вашей сети, но вам нужен Varonis, чтобы получить полное представление о том, что они делают и к каким конфиденциальным данным получают доступ.

    Узнайте, как Varonis помогает завершить авторизацию -> доступ к изображению сейчас:

    Примеры OAuth

    Самый простой пример OAuth в действии — это один веб-сайт, говорящий: «Эй, не хотите ли вы войти на наш веб-сайт, используя логин другого веб-сайта?» В этом сценарии единственное, что нужно сделать первому веб-сайту — назовем этот веб-сайт 9-м. 0042 потребитель — хочет знать, что пользователь является одним и тем же пользователем на обоих веб-сайтах и ​​успешно вошел в систему поставщика услуг — это сайт, на который первоначально вошел пользователь, а не потребитель.

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

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

    Объяснение OAuth

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

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


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

    Как работает OAuth

    В транзакции OAuth участвуют 3 основных участника: пользователь, потребитель и поставщик услуг. Этот триумвират ласково называют любовным треугольником OAuth.

    В нашем примере Джо — пользователь, Bitly — потребитель, а Twitter — предоставляемая служба, которая контролирует защищенный ресурс Джо (его поток в Твиттере). Джо хотел бы, чтобы Bitly мог публиковать сокращенные ссылки на его поток. Вот как это работает:

    Шаг 1. Пользователь демонстрирует намерение

    • Джо (пользователь): «Эй, Битли, я бы хотел, чтобы ты мог публиковать ссылки прямо на мой поток в Твиттере».
    • Bitly (Потребитель): «Отлично! Позвольте мне спросить разрешения».

    Шаг 2 — Потребитель получает разрешение

    • Bitly: «У меня есть пользователь, который хотел бы, чтобы я разместил пост в его потоке. Могу ли я получить токен запроса?»
    • Твиттер (поставщик услуг): «Конечно. Вот знак и секрет.

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

    Шаг 3. Пользователь перенаправляется к поставщику услуг

    • Побитовый: «Хорошо, Джо. Я отправляю вас в Twitter, чтобы вы могли одобрить. Возьми этот жетон с собой».
    • Джо: «ОК!»

    — Битли направляет Джо в Твиттер для авторизации >

    Это самое страшное. Если бы Bitly была супер-теневой Evil Co., она могла бы открыть окно, похожее на Twitter, но на самом деле это фишинг для вашего имени пользователя и пароля. Всегда проверяйте, что URL-адрес, на который вы перешли, действительно принадлежит поставщику услуг (в данном случае Twitter).

    Шаг 4. Пользователь дает разрешение

    • Джо: «Twitter, я хочу авторизовать этот токен запроса, который дал мне Bitly».
    • Твиттер: «Хорошо, просто чтобы убедиться, вы хотите разрешить Bitly делать X, Y и Z с вашей учетной записью Twitter?»
    • Джо: «Да!»
    • Twitter: «Хорошо, вы можете вернуться в Bitly и сказать им, что у них есть разрешение на использование токена запроса».

    Twitter помечает токен запроса как «годный», поэтому, когда потребитель запрашивает доступ, он будет принят (при условии, что он подписан с использованием их общего секрета).

    Шаг 5 — Потребитель получает маркер доступа

    • Bitly: «Twitter, могу ли я обменять этот токен запроса на токен доступа?»
    • Twitter: «Конечно. Вот ваш токен доступа и секрет».

    Шаг 6 — Потребитель получает доступ к защищенному ресурсу

    • Bitly: «Я хотел бы опубликовать эту ссылку на стрим Джо. Вот мой токен доступа!»
    • Twitter: «Готово!»

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

    Сравнение OAuth 1.0 и OAuth 2.0

    OAuth 2.0 — это полностью переработанная версия OAuth 1.0, и они несовместимы. Если вы создаете новое приложение сегодня, используйте OAuth 2.0. Этот блог относится только к OAuth 2.0, так как OAuth 1.0 устарел.

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

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

    Другие ресурсы

    Надеюсь, это был хороший учебник для знакомства с OAuth, поэтому в следующий раз, когда вы увидите «Войти через Twitter» или аналогичную делегированную проверку личности, у вас будет хорошее представление о том, что происходит.

    Если вы хотите глубже погрузиться в механику OAuth, вот несколько полезных ссылок:

    • http://marktrapp.com/blog/2009/09/17/oauth-манекены
    • http://stackoverflow.com/questions/4113934/how-is-oauth-2-other-from-oauth-1
    • http://googlecodesamples.com/oauth_playground/

    Что вам следует сделать сейчас

    Ниже приведены три способа, которыми мы можем помочь вам начать путь к снижению риска данных в вашей компании:

    1. Запланируйте демонстрационный сеанс с нами, где мы можем показать вам, ответить на ваши вопросы и помочь вы увидите, подходит ли вам Варонис.
    2. Загрузите наш бесплатный отчет и узнайте о рисках, связанных с раскрытием данных SaaS.
    3. Поделитесь этой записью в блоге со своими знакомыми, которым будет интересно ее прочитать. Поделитесь им с ними по электронной почте, LinkedIn, Twitter, Reddit или Facebook.
    Роб Соберс

    Роб Соберс — инженер-программист, специализирующийся на веб-безопасности, и соавтор книги Learn Ruby the Hard Way.

    Получите бесплатную оценку рисков

    Вы не можете защитить то, что, как вы не знаете, уязвимо.

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

    Начните оценку рисков

    Продолжайте читать

    Что такое OAuth 2.0 и чем он вам полезен?

    • Введение в IAM
    • Что такое OAuth 2. 0?

    OAuth 2.0, что означает «Открытая авторизация», — это стандарт, разработанный для предоставления веб-сайту или приложению доступа к ресурсам, размещенным другими веб-приложениями, от имени пользователя. Он заменил OAuth 1.0 в 2012 году и теперь является отраслевым стандартом де-факто для онлайн-авторизации. OAuth 2.0 обеспечивает согласованный доступ и ограничивает действия, которые клиентское приложение может выполнять с ресурсами от имени пользователя, никогда не передавая учетные данные пользователя.

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

    Принципы OAuth3.0

    OAuth 2.0 — это протокол авторизации, а НЕ протокол аутентификации. Таким образом, он разработан в первую очередь как средство предоставления доступа к набору ресурсов, например, к удаленным API или пользовательским данным.

    OAuth 2.0 использует токены доступа. Маркер доступа — это фрагмент данных, который представляет собой авторизацию для доступа к ресурсам от имени конечного пользователя. OAuth 2.0 не определяет конкретный формат токенов доступа. Однако в некоторых случаях часто используется формат JSON Web Token (JWT). Это позволяет эмитентам токенов включать данные в сам токен. Кроме того, по соображениям безопасности токены доступа могут иметь срок действия.

    Роли OAuth3.0

    Идея ролей является частью основной спецификации структуры авторизации OAuth3.0. Они определяют основные компоненты системы OAuth 2.0 и заключаются в следующем:

    • Владелец ресурса: Пользователь или система, которая владеет защищенными ресурсами и может предоставлять к ним доступ.

    • Клиент: Клиент — это система, которой требуется доступ к защищенным ресурсам. Для доступа к ресурсам Клиент должен иметь соответствующий Токен доступа.

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

    • Сервер ресурсов: Сервер, который защищает ресурсы пользователя и получает запросы на доступ от Клиента. Он принимает и проверяет токен доступа от клиента и возвращает ему соответствующие ресурсы.

    Области действия OAuth 2.0

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

    Токены доступа OAuth 2.0 и код авторизации

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

    Как работает OAuth 2.0?

    На самом базовом уровне, прежде чем можно будет использовать OAuth 2.0, клиент должен получить свои собственные учетные данные, _client id _ и секрет клиента , с сервера авторизации, чтобы идентифицировать и аутентифицировать себя при запросе токена доступа.

    При использовании OAuth 2.0 запросы на доступ инициируются Клиентом, например мобильным приложением, веб-сайтом, приложением Smart TV, настольным приложением и т. д. Запрос токена, обмен и ответ следуют следующему общему потоку:

    1. Клиент запрашивает авторизацию (запрос на авторизацию) с сервера авторизации, предоставляя в качестве идентификации идентификатор клиента и секрет; он также предоставляет области действия и URI конечной точки (URI перенаправления) для отправки токена доступа или кода авторизации.

    2. Сервер авторизации аутентифицирует Клиента и проверяет, разрешены ли запрошенные области.

    3. Владелец ресурса взаимодействует с сервером авторизации для предоставления доступа.

    4. Сервер авторизации перенаправляет обратно клиенту код авторизации или токен доступа, в зависимости от типа предоставления, как это будет объяснено в следующем разделе. Также может быть возвращен Refresh Token.

    5. С токеном доступа клиент запрашивает доступ к ресурсу с сервера ресурсов.

    Типы грантов в OAuth 2.0

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

    • Предоставление кода авторизации: сервер авторизации возвращает клиенту одноразовый код авторизации, который затем обменивается на токен доступа. Это лучший вариант для традиционных веб-приложений, где обмен может безопасно происходить на стороне сервера. Поток кода авторизации может использоваться одностраничными приложениями (SPA) и мобильными/собственными приложениями. Однако здесь секрет клиента не может быть надежно сохранен, поэтому аутентификация при обмене ограничивается использованием идентификатор клиента один. Лучшей альтернативой является код авторизации с грантом PKCE , как показано ниже.

    • Неявное предоставление: Упрощенный поток, при котором маркер доступа возвращается непосредственно клиенту. В неявном потоке сервер авторизации может вернуть токен доступа в качестве параметра в URI обратного вызова или в качестве ответа на сообщение формы. Первый вариант теперь устарел из-за потенциальной утечки токена.

    • Предоставление кода авторизации с ключом подтверждения для обмена кодами (PKCE): этот процесс авторизации аналогичен Предоставляется код авторизации , но с дополнительными шагами, которые делают его более безопасным для мобильных/собственных приложений и SPA.

    • Тип гранта учетных данных владельца ресурса: этот грант требует, чтобы клиент сначала получил учетные данные владельца ресурса, которые передаются на сервер авторизации. Поэтому он ограничен Клиентами, которым полностью доверяют. Его преимущество заключается в том, что не используется перенаправление на сервер авторизации, поэтому оно применимо в случаях использования, когда перенаправление невозможно.

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

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

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

    Хотите узнать больше?

    Продолжайте читать нашу страницу «Введение в IAM», чтобы узнать больше об управлении идентификацией и доступом.

    No related posts.