Oauth что это такое

OAuth 2.0 простым и понятным языком

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

Что такое OAuth 2.0

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

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

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

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

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

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

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

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

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

• авторизация для приложений, имеющих серверную часть (чаще всего, это сайты и веб-приложения)
• авторизация для полностью клиентских приложений (мобильные и 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:

Обратите внимание, если вы реализуете логин на сайте с помощью 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

Обратите внимание, что в последнем запросе используется 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:

Приложение должно перехватить последний редирект, получить из адреса 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&username=api@corp.mail.ru& password=qwerty < HTTP/1.1 200 OK < Content-Type: application/json

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

Обычно, 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

Минусы OAuth 2.0

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

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

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

Заключение

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

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

Ссылки

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

Что такое OAuth 2.0

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

Принципы OAuth2.0

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

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

Роли OAuth2.0

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

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

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

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

Токены и авторизационный код

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

Бесплатный тестовый доступ к облаку на 30 днейПолучить

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

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

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

1. Клиент посылает запрос на авторизацию с сервера передавая ID и секрет; он также предоставляет области действия и URI конечной точки (URI перенаправления) для отправки токена или авторизационного кода.
2. Сервер авторизации аутентифицирует Клиента, а также проверяет, разрешены ли запрошенные области.
3. Владелец ресурса взаимодействует с сервером для предоставления доступа.
4. Сервер авторизации перенаправляет обратно код или токен, в зависимости от типа предоставления. Также может быть возвращен Refresh Token.
5. С токеном клиент запрашивает доступ к ресурсу с сервера ресурсов.

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

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

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

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

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

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

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

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

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

В чём отличие с OpenID

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

Поток в OpenID выглядит аналогично OAuth, но в запросе применяется единый opened, а клиент получает access token и id token.

Протокол авторизации OAuth 2.0

OAuth 2.0 (RFC 6749) является фреймворком для авторизации, позволяющим получить сторонним приложениям ограниченный доступ к ресурсам HTTP-сервиса.

Стандарт OAuth 2.0 определяет следующие четыре роли:

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

Соответствие сущностей DSS ролям OAuth 2.0 имеет следующий вид:

• в качестве владельца ресурсов выступает Пользователь КриптоПро DSS;
• в качестве сервера ресурсов выступают компоненты DSS, содержащие данные Пользователя (например, Сервис Подписи, Сервис Аудита, Хранилище Документов и т.п.)
• клиентом является приложение, осуществляющее операции в DSS. Приложением может являться браузер, толстый клиент или мобильное приложение.
• ЦИ DSS выступает в роли сервера авторизации.

Согласно OAuth, Клиентское Приложение запрашивает доступ к ресурсу, находящемуся в ведении Пользователя. Вместо использования учетных данных Пользователя, Приложение получает маркер доступа — строку, включающую в себя атрибуты доступа к ресурсу. Данные маркеры выпускаются Центром Идентификации КриптоПро DSS с разрешения Пользователя (после его аутентификации).

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

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

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

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

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

Протокол определяет следующие типы разрешения на авторизацию:

• код авторизации (authorization code);
• неявный (implicit);
• учетные данные владельца ресурса (resource owner);
• учетные данные клиента (не используется КриптоПро DSS).

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

Под взаимодействием с пользователем понимается непосредственное взаимодействие Пользователя DSS c Веб-Интерфейсом Центра Идентикации в рамках авторизации клиентского приложения, в то время как сценарии без взаимодействия с Пользователем могут выполняться по схеме Service-Service.

К сценариям, требующим обязательное взаимодействие с пользователям, относятся:

• Авторизация с использованием кода авторизации
• Авторизация с использованием типа разрешения Implicit

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

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

OAuth 2.0 — основы понятным языком

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

Захоплюючий курс від laba: HR-менеджер.
Розвивайте персонал і підтримуйте бізнес.

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

Для реализации подобных сценариев (а также множества аналогичных) и предназначен стандарт OAuth 2.0.

Что такое OAuth 2.0?

OAuth 2.0 (RFC 6749) является открытым фреймворком авторизации, позволяющим получить сторонним приложениям ограниченный доступ к ресурсам HTTP-сервиса.

Ефективний курс від mate.academy: Frontend.
Розблокуйте світ веб-розробки.

История создания

OAuth появился в ноябре 2006 года, во время разработки Блейном Куком (англ. Blaine Cook) протокола OpenID для сервиса микроблогов Twitter. Совместно с Крисом Мессиной (англ. Chris Messina) он искал способ использования OpenID для доступа к Twitter API без предоставления сервису пароля. В сотрудничестве с одним из создателей OpenID Дэвидом Рекордоном (англ. David Recordon) они провели анализ функциональности OpenID, а также нескольких других проприетарных протоколов авторизации, и пришли к заключению о необходимости в новом, универсальном и открытом протоколе.

В апреле 2007 года образовалась группа инженеров, работавших над его созданием. В ее работе приняли участие сотрудники компаний Google и AOL. Финальная версия ядра протокола OAuth 1.0 была представлена 4 декабря 2007 года. 15 апреля 2009 года Twitter предложил пользователям решение, позволяющее делегировать сторонним сайтам и сервисам доступ к своим аккаунтам. Оно было названо «Войти через Twitter» и основано на OAuth.

В апреле 2010 года был выпущен информационный документ RFC 5849, посвященный стандарту OAuth. В 2010 году началась работа над новой версией протокола OAuth 2.0. В октябре 2012 года структура OAuth 2.0 была опубликована в RFC 6749, а использование носителя токена регламентировано в RFC 6750. Вторая версия была несовместима с первой.

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

В результате в новый протокол было внесено несколько важных изменений:

• Упрощенная подпись. Подпись была значительно упрощена, чтобы устранить необходимость в специальном анализе, кодированиях и сортировках параметров.
• Короткоживущие токены с долговременной авторизацией. Вместо выдачи долгоживущего токена (который за длительное время может быть скомпрометирован), сервер предоставляет кратковременный доступ и долговременную возможность обновлять токен без участия пользователя.
• Разделение ролей. За авторизацию и за предоставление доступа к API могут отвечать разные серверы.

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

Ефективний курс від laba: Фінансовий менеджер.
Оптимізуйте фінансовий розвиток компанії.

Отличие от OpenID

Часто можно услышать такой вопрос. А зачем нужен OAuth, если существует OpenID? Хотя OAuth и OpenID имеют много общего, между ними есть принципиальная разница:

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

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

Стандарт OAuth 2.0 определяет следующие четыре роли :

1. владелец ресурса — сущность, обладающая правом на выдачу доступа к защищенным ресурсам. В случае если владелец является человеком, его называют конечным пользователем;
2. сервер ресурсов — сервер, содержащий защищаемые ресурсы и обладающий возможностью получения и формирования ответа на запросы к защищаемым ресурсам посредством использования маркера доступа;
3. клиент — приложение, осуществляющее доступ к защищенным ресурсам от имени владельца. Термин «клиент» явно не определяет какое-либо конкретное исполнение (будь то сервер, персональный компьютер или мобильное приложение);
4. сервер авторизации — сервер, осуществляющий выпуск маркеров доступа для клиентских приложений после успешной аутентификации и авторизации владельца ресурсов.

Общая схема взаимодействия выглядит следующим образом:

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

Стратегічний курс від laba: Business English для фінансистів.
Завоюйте світовий ринок.

Таким образом имеется:

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

1. Клиент запрашивает у конечного пользователя прохождение авторизации на сервере авторизации (в приведенном примере, это когда пользователя перенаправляют на страницу логина Facebook, затем запрашивают разрешение на доступ из приложения клиента).
2. После того как конечный пользователь авторизовался, клиент получает грант авторизации. (Фактически грант авторизации клиенту выдает сервер авторизации, после того как конечный пользователь авторизовался и подтвердил выдачу запрашиваемых клиентом прав.)
3. Клиент запрашивает у сервера токен доступа. При этом клиент предоставляет некоторые идентификационные данные о себе и грант авторизации от пользователя. Токен доступа представляет собой альтернативу логину и паролю, имеет ограниченное время действия и связан с определенными ограничениями прав. Отметим, что клиент должен быть предварительно зарегистрирован на сервере авторизации, чтобы можно было его идентифицировать.
4. Если подлинность клиента подтверждена и разрешение на авторизацию действительно, сервер авторизации создает токен доступа для клиента и передает его. Авторизация завершена.
5. Клиент использует токен доступа для аутентификации на сервере авторизации.
6. Клиент получает доступ к необходимым ресурсам (читает данные аккаунта пользователя Facebook и создает на ее основе свою учетную запись).

Итак, чтобы запросить токен доступа, клиент получает авторизацию от владельца ресурса. Разрешение выражается в виде гранта авторизации ( authorization grant ), который клиент использует для запроса токена доступа ( access token ). OAuth определяет четыре типа предоставления:

1. код авторизации ( authorization code ),
2. неявный ( implicit ),
3. учетные данные владельца ресурса,
4. учетные данные клиента.

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

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

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

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

Пример

Примеры приводятся для API Mail.Ru. Перенаправляем браузер пользователя на страницу авторизации:

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

client_id и client_secret — значения, полученные при регистрации приложения на платформе. После того, как пользователь выдаст права, происходит перенаправление на указанный redirect_uri :

Используем полученный code (код авторизации) для получения токена доступа, выполняя запрос с сервера:

> 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

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

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

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

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

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

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

Пример

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

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

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

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

Учетные данные владельца ресурса (Авторизация по логину и паролю)

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

Пример

> 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

Учетные данные клиента

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

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

Обычно, токен доступа имеет ограниченный срок годности. Чтобы не заставлять пользователя проходить авторизацию после истечения срока его действия, во всех перечисленных выше вариантах в дополнение к токену доступа может возвращаться еще токен обновления. По нему можно получить новый токен доступа с помощью 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

Зачем нужен Authorization Code

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

Дело в том, что это безопаснее. Канал между приложениями (клиентом и сервером ресурсов) безопасный ( back сhannel ). А канал запросов, проходящих через браузер ( front channel ), — нет. Код авторизации проходит через браузер: он возвращается в url при перенаправлении обратно на клиент. Для обращения к ресурсам прошедший через браузер код авторизации не очень подходит. Его относительно легко может перехватить злоумышленник. Поэтому он заменяется на токен доступа, пересылаемый через безопасный канал ( back сhannel ). Кроме того, без секрета клиента ( client-secret , который также передается по back сhannel ) токен доступа не получить, что обеспечивает дополнительную безопасность.

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

Допустим, кто-то завладел вашим токеном доступа и получил доступ к защищенным данным. Именно поэтому у токенов есть срок годности. У токена доступа он обычно небольшой — от нескольких секунд до нескольких дней, у токена обновления — много больше. Так вот: доступ к данным у злоумышленника будет до тех пор, пока токен доступа не «протухнет», то есть недолго.

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

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

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

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

Из минусов:

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

Итоги

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

В целом, OAuth 2.0 исправляет недостатки OAuth 1.0, но имеет ряд своих недостатков. На данный момент он все еще находится в развитии. Следующая ожидаемая версия стандарта — OAuth 2.1.

Закрепить озвученный материал можно в этом тематическом видео: