Сайт о телевидении

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&username=api@corp.mail.ru& 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", < }

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

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

• 6 новых потоков.

Поток пользователя – агента (User-Agent Flow) - для клиентов, работающих внутри агента пользователя (обычно веб-браузер). Поток веб – сервера (Web Server Flow) - для клиентов, которые являются частью веб-приложения сервера, доступные через запросы HTTP . Поток устройства (Device Flow) - подходит для клиентов, выполняющихся на ограниченных устройствах, но там, где конечный пользователь имеет отдельный доступ к браузеру на другом компьютере или устройстве. Поток имени пользователя и пароля(Username and Password Flow) - используется в тех случаях, когда пользователь доверяет клиенту обрабатывать свои полномочия, но он по-прежнему нежелательно разрешит клиенту сохранить имя и пароль пользователя. Этот поток подходит только когда есть высокая степень доверия между пользователем и клиентом. Поток клиентских полномочий (Client Credentials Flow) - клиент использует свои полномочия для получения токена. Поток утверждения (Assertion Flow) - клиент представляет утверждение, такие как утверждение SAML к серверу авторизации в обмен на токен. Приложения, работающие на настольном компьютере или мобильном устройстве может быть реализованы с использованием выше сказанных потоков.

• Токен на предъявителя.

Метод авторизации аналогичен существующему способу авторизации с помощью cookie . В этом случае токен непосредственно используется как секрет (сам факт наличия токена авторизует клиента) и передается через HTTPS . Это позволяет получать доступ к API посредством простых скриптов (например, с использованием cURL).

• Упрощенная подпись.

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

• Короткоживущие токены с долговременной авторизацией.

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

• Разделение ролей.

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

Стоит отметить, что, хотя стандарт OAuth 2.0 ещё не утвержден, он уже используется некоторыми сервисами. Например, Graph API социальной сети Facebook поддерживает только OAuth 2.0.

Отличие OAuth от OpenID

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

Метка времени и Nonce

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

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

Полномочия и токены

OAuth используется три вида полномочий: учетные данные клиента (consumer key and secret или client credentials), временные учетные данные (request token and secret или temporary credentials) и токены (access token and secret или token credentials).

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

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

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

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

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

Схема работы протокола OAuth

Поясним работу протокола OAuth на примере . Допустим, что пользователь (владелец ресурсов) хочет распечатать свои фотографии (ресурсы), загруженные на сайт «photos.example.net» (сервер), при помощи сервиса печати «printer.example.net» (клиент).

1. Клиент посредством протокола HTTPS отправляет серверу запрос, который содержит идентификатор клиента, метку времени, адрес обратного вызова по которому нужно вернуть токен, используемый тип цифровой подписи и саму подпись.
2. Сервер подтверждает запрос и отвечает клиенту токеном доступа (Access Token) и частью разделённого секрета.
3. Клиент передает токен владельцу ресурсов (пользователю) и перенаправляет его на сервер для прохождения авторизации.
4. Сервер, получив от пользователя токен, запрашивает у него его логин и пароль, и в случае успешной аутентификации просит пользователя подтвердить доступ клиента к ресурсам (авторизация), после чего пользователь перенаправляется сервером к клиенту.
5. Клиент передает серверу токен посредством протокола TLS и запрашивает доступ к ресурсам.
6. Сервер подтверждает запрос и отвечает клиенту новым токеном доступа.
7. Используя новый токен, клиент обращается к серверу за ресурсами.
8. Сервер подтверждает запрос и предоставляет ресурсы.

Данный пример описывает поток с кодом подтверждения (Authorization Code Flow). Помимо этого в стандарте OAuth 2.0 описаны следующие потоки:

• Поток неявного доступа (Implicit Grant Flow)

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

• Поток с обновляемым токеном (Refreshing an Expired Access Token Flow)

Отличия данного потока от приведённого примера в следующем: на шаге 2 сервер помимо токена доступа, который имеет ограниченное время жизни, выдает токен обновления; на шаге 8 сервер проверяет, является ли токен доступа валидным (в смысле истечения времени жизни), и в зависимости от этого либо предоставляет доступ к ресурсам, либо требует обновления токена доступа (который предоставляется при предъявлении токена обновления).

• Поток с предоставлением клиенту пароля (Resource Owner Password Credentials Flow)

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

• Поток клиентских полномочий (Client Credentials Flow)

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

OAuth поддерживает два метода аутентификации сообщений от клиента: HMAC -SHA1 и RSA -SHA1 . Есть возможность передавать сообщения без подписи, тогда в поле типа подписи указывается «plain text ». Но в этом случае, согласно спецификации, соединение между клиентом и сервером должно устанавливаться через протокол SSL или TLS .

Порталы, использующие OAuth

Дискуссия

В июле 2012 года, Эран Хаммер (Eran Hammer), действующий редактор стандарта OAuth 2.0, объявил об уходе с поста после трех лет работы над новым стандартом, и попросил вычеркнуть своё имя из спецификаций. Он говорил о своих взглядах на своем сайте . Он позже выступил с докладом. .

Примечания

См. также

Ссылки

Wikimedia Foundation . 2010 .

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

Создание учетных данных OAuth2

Чтобы создать учетные данные OAuth2, выполните перечисленные ниже действия.

Определение типа приложения

Во-первых, нужно определить тип приложения , которое вы хотите создать. В AdWords API существует два типа приложений:

• устанавливаемое приложение (рекомендуется);
• веб-приложение.

С помощью приведенной ниже таблицы определите нужный тип приложения.

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

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

Создание идентификатора и секретного кода клиента

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

Устанавливаемое приложение

1. Откройте
2. Создать проект Создать .
3. Создать учетные данные , а затем – Идентификатор клиента OAuth .
4. Сохранить
5. В разделе Тип приложения выберите Другие типы и укажите необходимую информацию.
6. Нажмите Создать .
7. идентификатор и секретный ключ

Веб-приложение

1. Откройте
2. В раскрывающемся меню проектов выберите Создать проект , затем укажите название проекта и при необходимости измените его идентификатор, после чего нажмите кнопку Создать .
3. На странице "Учетные данные" выберите Создать учетные данные , а затем – Идентификатор клиента OAuth .
4. Вам может быть предложено указать название продукта. В этом случае нажмите Настроить окно запроса доступа , укажите запрашиваемую информацию и нажмите Сохранить , чтобы вернуться к экрану "Учетные данные".
5. В разделе Тип приложения выберите Веб-приложение . Следуя инструкциям, укажите источники JavaScript и/или URI перенаправления.
6. Нажмите Создать .
7. На появившейся странице скопируйте идентификатор и секретный ключ клиента – они понадобятся вам при настройке клиентской библиотеки.

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

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

OAuth2 Playground

Альтернативный вариант создания учетных данных OAuth2 состоит в использовании OAuth2 Playground . В сочетании с Google API Console эта система позволяет самостоятельно создавать токены OAuth2.

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

Настройка

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

Как получить идентификатор и секретный ключ клиента

1. Откройте
2. В раскрывающемся меню выберите существующий проект или создайте новый.
3. На странице "Учетные данные" выберите Создать учетные данные , а затем – Идентификатор клиента OAuth .
4. В разделе Тип приложения выберите Веб-приложение .
5. В разделе добавьте следующую строку: https://сайт/oauthplayground
6. Нажмите Создать .
7. Запишите идентификатор и секретный ключ клиента, указанные на появившейся странице. Они понадобятся вам на следующем шаге.

Как создать токены

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

Как убрать OAuth2 Playground из идентификатора клиента

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

1. Перейдите на .
2. В раскрывающемся меню выберите свой проект.
3. На странице "Учетные данные" выберите название идентификатора клиента.
4. Удалите https://сайт/oauthplayground в поле Разрешенные URI перенаправления . Обратите внимание, что необходимо оставить хотя бы один URI перенаправления.
5. Нажмите Сохранить .

Итак, у вас есть учетные данные OAuth. Теперь можно осуществлять запросы AdWords API и использовать для требуемой клиентской библиотеки.

Сервисные аккаунты OAuth2

В этом разделе описывается порядок доступа к AdWords API с использованием сервисных аккаунтов.

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

AdWords API разрешает доступ сервисного аккаунта через домены G Suite .

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

Применение сервисных аккаунтов дает два существенных преимущества:

• Авторизация доступа приложения к API Google осуществляется на этапе настройки. Это позволяет избежать трудностей, связанных с необходимостью вмешательства пользователя или кеширования токенов в других потоках OAuth2.
• Олицетворение других пользователей в приложении при необходимости осуществляется в рамках процесса утверждения OAuth2.

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

Альтернатива сервисным аккаунтам

Сервисные аккаунты широко применяются для обеспечения программного доступа к API по протоколу OAuth2 без вмешательства пользователя.

Однако настроить такие аккаунты для работы с AdWords API непросто. Более простой альтернативой является с сохраняемым токеном обновления. Такой подход позволяет приложению в любой момент запрашивать новые токены доступа.

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

Требования

• Принадлежащий вам домен G Suite , например mydomain.com или mybusiness.com.
• Токен разработчика AdWords API и желательно тестовый аккаунт.
• для используемого языка.

Настройка доступа для клиентского аккаунта

Во-первых, необходимо создать ключ служебного аккаунта в Google API Console.

1. Войдите в аккаунт G Suite, откройте .
2. В раскрывающемся меню проектов выберите Создать проект , затем укажите требуемую информацию и нажмите кнопку Создать . Новый проект появится в списке активных.
3. В меню в левом верхнем углу выберите IAM и администрирование , а затем – Сервисные аккаунты в меню слева.
4. Нажмите Создать сервисный аккаунт вверху страницы.
5. Укажите название сервисного аккаунта.
6. Установите флажок Создать новый закрытый ключ и выберите тип ключа JSON.
7. Установите флажок Включить делегирование доступа к данным в домене G Suite и укажите название продукта для окна запроса доступа.
8. Нажмите Создать . Запустится скачивание файла ключа JSON. Сохраните файл в надежном месте, куда только у вас есть доступ.
9. На странице Сервисные аккаунты появится новый сервисный аккаунт.

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

Проблемы безопасности

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

Кроме того, рекомендуется предоставлять каждому аккаунту сервиса доступ только к одному API Google. Для этого используется поле scope , которое описывается в следующем разделе. Такая профилактическая мера позволяет ограничить объем данных, открытый для несанкционированного доступа в случае компрометации файла ключа.

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

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

Теперь вы можете осуществлять доступ к аккаунту AdWords с использованием сервисного аккаунта в рамках процесса утверждения OAuth2.

Настройка клиентской библиотеки

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

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

Оптимизация запросов OAuth2

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

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

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

Стратегии распределения учетных данных

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

Стратегия распределения учетных данных зависит от структуры приложения.

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

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

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

Ниже описаны стратегии для аутентификации одного аккаунта AdWords, например управляющего аккаунта верхнего уровня в иерархии.

Затем описывается, как адаптировать эти стратегии для .

Многопоточные приложения

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

На этой схеме показаны потоки, передающие запросы в AdWords API во время выполнения. Применяется общий пул сеансов (пользователей). Обратите внимание, что каждый сеанс должен использовать один и тот же объект учетных данных. В ответ на каждый запрос API поток получает соответствующий сеанс (пользователя). Если требуется обновить токен доступа, это нужно делать синхронно, чтобы исключить состояние гонки. Другими словами, объект учетных данных должен быть потокобезопасным.

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

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

Многопроцессные и распределенные приложения

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

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

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

Задача обновления

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

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

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

Хранилище данных

Хранилище данных используется для предоставления учетных данных разным процессам и серверам.

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

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

Помните, что учетные данные нужно хранить в защищенном виде .

При сохранении учетных данных необходимо сохранять свойство expiry_time (текущее время + expires_in) и refresh_token вместе со свойством access_token . Свойство expiry_time (окончание действия токена) рассчитывается по такой формуле: время запроса на обновление access_token + время expires_in (срок действия токена).

Пул серверов

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

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

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

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

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

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

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

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

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

Примечание . AdWords API пока не поддерживает одновременный вход с помощью запроса на доступ к данным (гибридная схема) или делегирование полномочий на уровне домена (2LO).

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

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

Ниже представлены текущая и устаревшая область действия для AdWords API.

Автономный доступ

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

Устанавливаемые приложения используют автономный доступ по умолчанию.

Заголовок запроса HTTP

Заголовок HTTP в каждом запросе к серверу AdWords API должен включать в такой форме:

Authorization: Bearer THE_ACCESS_TOKEN

POST … HTTP/1.1 Host: … Authorization: Bearer 1/fFAGRNJru1FTz70BzhT3Zg Content-Type: text/xml;charset=UTF-8 Content-Length: … …

Токены доступа и обновления

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

Когда истекает срок действия токена доступа

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

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License , and code samples are licensed under the Apache 2.0 License . For details, see our . Java is a registered trademark of Oracle and/or its affiliates.

Обновлено Сентябрь 24, 2018

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

Пример кросс-авторизации

Вернемся в 2005-й год и представим, что мы пишем социальную сеть. В ней имеется форма импорта контактов из адресной книги GMail. Что нужно для доступа к контактам GMail? Конечно, логин и пароль от ящика. Но если мы попросим ввести их на нашем сайте, пользователь заподозрит неладное. Где гарантия, что мы не сохраняем на сервере введенные пароли? Поэтому нам хочется, чтобы пароль вводился только на сайте GMail , и после этого доступ к контактам через API GMail предоставлялся нашей социальной сети (возможно, на время). Договоримся о терминах.

• Consumer : потребитель; скрипт обработки формы импорта контактов в социальной сети.
• Service Provider : поставщик данных; GMail, содержащий в себе данные адресной книги, интересные для Consumer-а.
• User : пользователь, имеющий аккаунт как у Consumer-а, так и у Service Provider-а.
• Protected Resource : личные данные; контакты из адресной книги на GMail (т.е. ресурсы Service Provider-а).
• Provider API : API GMail, позволяющий любому скрипту получить контакты из адресной книги GMail.

Задача OAuth - сделать так, чтобы User имел возможность работать на сервисе Consumer (в соцсети) с защищенными данными Service Provider-а (GMail), вводя пароль к этим данным исключительно на Service Provider-e и оставаясь при этом на сайте Consumer-а. Не так уж и сложно, верно?

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

OAuth часто называют «протоколом для роботов», в отличие от OpenID - «протокола для пользователей». Не путайте их!

1. OpenID - протокол для ускоренной регистрации. OpenID позволяет пользователю без ввода пароля получить аккаунт на каком-либо сервисе, если он уже зарегистрирован где-то еще в интернете. (И потом можно без ввода пароля входить на сервис, будучи авторизованным «где-то».) Например, если у вас есть аккаунт на Яндексе, вы сможете «входить» с его помощью на любой сервис, поддерживающий OpenID-авторизацию.
2. OAuth - протокол для авторизованного доступа к стороннему API. OAuth позволяет скрипту Consumer-а получить ограниченный API-доступ к данным стороннего Service Provider-а, если User дает добро. Т.е. это средство для доступа к API.

Милицейская аналогия Представьте, что вы - сотрудник Уголовного розыска, ищущий концы в деле о краже WebMoney за 1973-й год. Договоримся о терминах: OAuth Consumer : Уголовный розыск. User : сотрудник Уголовного розыска. Service Provider : Картотека архива преступлений. OpenID: сотрудник Уголовного розыска (User) приходит в Картотеку (Service Provider), предъявляет на входе ксиву (Authorization) и на месте перебирает карточки в поисках информации. OAuth: сотрудник Уголовного розыска (User) прямо с работы (Consumer) звонит в Картотеку (Service Provider). Он докладывает свою фамилию; если его узнают (Authorization), он просит предоставить список всех преступлений за 1973-й год (API call). Как видите, OpenID и OAuth - разные вещи. OpenID позволяет вам прямо на месте получить доступ к некоторым ресурсам. OAuth обеспечивает получение части информации с удаленного сервиса через API.

План этой статьи

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

1. Рассмотрим проблемы, которые возникают при «ручной» реализации кросс-авторизации.
2. Поговорим о том, что такое «приложение» и кто такой Consumer.
3. Коснемся основ криптографии.
4. Обозначим демо-приложение, которое мы будем писать в этой статье.
5. Определимся с тестовым сервером OAuth, на котором будем экспериментировать.
6. Пройдем по всем шагам протокола OAuth и приведем исходники скрипта.

Об изобретении велосипедов

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

Во-первых, напишем саму форму импорта контактов с GMail:Далее попросим разработчиков GMail сделать так, чтобы при переходе пользователя по URI /auth.php ему бы выдавалась форма авторизации (в нашем веломире GMail написан на PHP). После успешного ввода пароля пользователь должен редиректиться на сайт, чей URL указан в параметре retpath. Также дополнительно в URL должен передаваться некоторый секретный ключ, который уже можно использовать для доступа к API GMail.

Итак, после ввода пароля пользователь будет возвращаться к нам на сайт по следующему адресу:А мы из скрипта /import.php обратимся к API GMail, передадим в него ключ Y49xdN0Zo2B5v0RR и загрузим контакты:Ну что же, давайте теперь считать грабли (потому что шишки считать будет уже поздно).

Грабли первые: подмена адреса возврата retpath

Ну конечно же, вы догадались, что злоумышленник на своем сайте первым делом разместит ссылкуи заставит вас на нее кликнуть. В результате он получит секретный ключ, который вернул GMail, а значит, и ваши контакты:

Грабли вторые: «подслушивание» секретного ключа

Предположим, мы как-то защитили retpath, и он теперь может указывать только на наш сайт. Но проблема с параметром secret остается.Secret можно подсмотреть из-за спины или перехватить методом прослушивания WiFi-трафика. Или на вашем сайте когда-нибудь найдется XSS-уязвимость, позволяющая «утянуть» секретный ключ. Имея значение secret, злоумышленник сможет прочитать вашу адресную книгу. Значит, нужно обезопасить secret от перехвата (в идеале - вообще его не передавать через URL).

Грабли третьи: слишком много редиректов

Если для каждого вызова API требуется разный secret, то нам придется организовывать столько редиректов на сайт Service Provider-а, сколько у нас вызовов. При интенсивном использовании API это работает очень медленно, да и неудобно порядком…

Грабли четвертые: плохая идентификация Consumer-а

GMail, конечно, хочет знать, кто пользуется его API. Разрешить доступ одним сайтам и запретить - другим… Значит, при формировании запроса в форме импорта контактов Consumer (сайт) должен «представляться» Service Provider-у (GMail-у). В нашем случае эту функцию частично выполняет retpath (имя сайта в нем), но данный способ не универсален, т.к. механизм «представления» должен быть задейстсован еще и при вызове API-методов.

Фундамент OAuth

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

Приложение = Consumer + доступ к API

При работе с OAuth важно, что термин Consumer не ограничивается смыслом «сайт». Consumer - это некоторое приложение , а уж где оно размещено, не так важно. Примеры Consumer-ов из реальной жизни: Но из одного OAuth каши не сваришь. Действительно, все, что дает OAuth, - это возможность авторизоваться на удаленном сервисе (Service Provider) и делать автризованные запросы к API. Не важно, как устроен этот API: это может быть чистый SOAP, REST-подход т. д. Главное, чтобы каждый метод API принимал на вход специальные параметры, передаваемые согласно протоколу OAuth.

Token = Key + Secret

Один из принципов OAuth гласит, что никакие секретные ключи не должны передаваться в запросах открытыми (выше в примере мы рассматривали, почему). Поэтому протокол оперирует понятием Token. Токен очень похож на пару логин + пароль: логин - открытая информация, а пароль - известен только передающей и принимающей стороне. В терминах OAuth аналог логина называется Key, а аналог пароля - Secret. Ситуация, когда Secret известен только отправителю и получателю, но более никому, называется Shared Secret.

Итак, если Consumer и Provider каким-то образом договорятся между собой о Shared Secret, они могут открыто обмениваться в URL соответствующими ключами (Key), не опасаясь, что перехват этих ключей будет опасен. Но как защитить URL с Key от подделки?

Сообщение = Документ + Цифровая подпись

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

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

Как это работает? Пусть наш $sharedSecret = 529AeGWg, и мы сообщили его шепотом на ухо принимающей стороне. Мы хотим передать сообщение «Мой телефон 1234567» с гарантированной защитой от фальсификации злоумышленником.

1. Consumer добавляет цифровую подпись к сообщению, в общем виде - $transfer = $message . "-" . md5($message . $sharedSecret); // $transfer = "Мой телефон 1234567" . "-" . md5("Мой телефон 1234567" . "529AeGWg")
2. Service Provider принимает данные, разбивает их обратно на 2 части - $message и $signature - и проделывает точно такую же операцию: $signatureToMatch = md5($message . $sharedSecret); // $signatureToMatch = md5("Мой телефон 1234567" . "529AeGWg"); Дальше остается только сравнить получившееся значение $signatureToMatch с тем, что было в полученных данных $signature и рапортовать о подделке, если значения не совпали.

Демонстрация работы OAuth на примере простого приложения

Чтобы «вживую пощупать» OAuth, нам потребуются две вещи:

1. Скрипт, реализующий клиентскую часть протокола. Я написал как раз такой небольшой PHP-скрипт (ссылка на zip-архив). Это виджет, который можно вставлять на PHP-сайты.
2. Тестовый сервер OAuth, на котором мы сможем экспериментировать. Для этой цели удобно использовать РуТвит: там есть страница http://rutvit.ru/apps/new , которая позволяет добавить тестовое приложение за 30 секунд. (Кстати, URL возврата в форме можно не указывать - мы все равно передаем его из тестового скрипта.)

Глядя на код демо-скрипта и читая пояснения ниже в статье, можно разобраться с деталями протокола.

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

1. Скачайте код скрипта и разверните его в любую удобную директорию на веб-сервере.
2. Зарегистрируйте новое тестовое приложение на OAuth-сервере.
3. После регистрации приложения замените параметры OA_CONSUMER_KEY и OA_CONSUMER_SECRET в скрипте на значения, полученные от сервера.

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

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

После регистрации приложения вам выдается 5 параметров, которые требуются для работы с OAuth. Вот как они могут выглядеть:

Здесь Consumer key и Consumer secret - это своеобразные «логин + пароль» вашего приложения (помните выше разговор о токенах? это как раз один из них). Напомню, что Consumer secret - это Shared Secret, известный только отправителю и получателю, но никому больше. Остальные 3 значения задают служебные URL, смысл которых мы сейчас рассмотрим.

OAuth = Fetch Request Token + Redirect to Authorization + Fetch Access Token + Call API

В примере с GMail мы использовали 2 вида удаленных вызовов: а) редирект через браузер; б) обращение к API изнутри скрипта.

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

1. Обработка отправки формы. Это не часть OAuth, а часть нашего приложения. Прежде чем обращаться к API Provider-а, мы должны получить от пользователя заказ-наряд на это действие. Вот пример такого «заказа»:
2. Fetch Request Token (внутренний запрос).
   • Скрипт Consumer-а обращается к Request token URL Provider-а: например, api.rutvit.ru/oauth/request_token . В запросе передается Consumer key - «логин приложения», а сам запрос подписывается при помощи Consumer secret - «пароля приложения», что защищает его от подделки.
   • В ответ Provider генерирует и возвращает «заполненный мусором» токен, который называется Request Token. Он нам еще пригодится, поэтому мы должны сохранить его где-нибудь - например, в сессионной переменной $S_REQUEST_TOK.
3. Redirect to Authorization (через редирект в браузере). Теперь у нашего приложения есть уникальный Request Token. Требуется получить у пользователя разрешение на использование этого токена, т.е. попросить его авторизовать Request Token .
   • Consumer редиректит браузера на специальный Authorize URL Provider-а: например, api.rutvit.ru/oauth/authorize . В параметрах передается Request Token Key.
   • Provider выводит форму авторизации для своего пользователя и, если он авторизовался, редиректит браузер назад. Куда именно? А мы указываем это в параметре oauth_callback.
4. Fetch Access Token (внутренний запрос). Итак, браузер вернулся в наше приложение после серии редиректов. Это значит, что авторизация на Provider-е прошла успешно, и Request Token разрешен к работе. Однако в OAuth для безопасности каждый токен имеет свое собственное, строго ограниченное назначение. Например, Request Token используется только для получения подтверждения от пользователя, и больше ни для чего. Для доступа к ресурсам нам нужно получить новый токен - Access Token - или, как говорят, «обменять Request Token на Access Token».
   • Consumer обращается к Access token URL - например, api.rutvit.ru/oauth/access_token , - и просит выдать ему Access Token взамен имеющегося у него Request Token-а. Запрос подписывается цифровой подписью на основе Request Token secret.
   • Provider генерирует и возвращает Access Token, заполненный «мусором». Он также помечает в своих таблицах, что для этого Access Token-а разрешен доступ к API. Наше приложение должно сохранить у себя Access Token, если оно собирается использовать API в дальнейшем.
5. Call API (внутренний запрос). Ну что же, теперь у нас есть Access Token, и мы можем передавать его key при вызове методов API.
   • Consumer генерирует запрос к API Provider-а (например, используя POST-запрос согласно REST-идеологии). В запросе передается Access Token Key, а подписывается он при помощи Shared Secret этого токена.
   • Provider обрабатывает API-вызов и возвращает данные приложению.

Конец скрипта: вывод виджета

Окончание скрипта должно быть понятно и без подробных разъяснений.

Листинг 14: Окончание скрипта: вывод виджета

// конец case } } // Получаем все имеющиеся твиты. $text = file_get_contents("http://api.rutvit.ru/search.xml?rpp=5&q=" . urlencode("#" . TAG)); $TWEETS = new SimpleXMLElement($text); // Shortcut для вывода сообщения с перекодировкой и квотингом. function e($text, $quote = 1) { $text = iconv("utf-8", ENCODING, $text); echo $quote? htmlspecialchars($text) : $text; } ?> status as $tweet) {?> user->screen_name)?>: text_formatted, 0)?> ?action=form_is_sent" style="margin: 1em 0 0 0">

Полезные ссылки по OAuth

• rutvit

Добавить метки

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

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


Из любопытства перешел по ссылке и попал на очередной фишинговый сайт. Но мне показалась странной сама ссылка, она имела вид (половина символов в ASCII):
vkontakte.ru/away.php ?to =http%3A%2F%2FApi.vKontakte.Ru%2F%2Fo%2561u%2574%…

Тут-то самое интересное и начинается...

Разберем вторую ссылку по частям:

Что означает каждый из параметров:

• client_id - ID приложения, требующего авторизацию;
• redirect_uri - адрес, на который будет передан access_token (посредством редиректа);
• display - вид окна авторизации (page, popup, touch и wap).

Собственно в redirect_uri содержался адрес фишинг сайта. Так как в параметре display была допущена ошибка (в него шел мусор "?390852"), окно авторизации не выводилось, а сразу шел редирект на фишинг сайт с параметрами: error=invalid_request&error_description=Invalid+display+passed

В этом и заключается весь смысл обхода блек-листа вредоносных сайтов ВКонтакте. Появляется только алерт о переходе на api.vk.com. И в результате перехода мы прямиком попадаем на фишинг сайт, который имеется в черном списке. При переходе по ссылке vkontakte.ru/away.php?to=vgostivk.dyndns**:

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

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

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

По идее после успешной «активации» должно было перекинуть на страницу activ.php, но я не смог попасть туда. Выдержки из JS скриптов фишинг сайта:

...
if (req.status == 200) {
// если статус 200 (ОК) - выдать ответ пользователю
if (req.responseText == "ok" ) {
//statusElem.innerHTML = "Все гуд!";
get_activation();
}
if (req.responseText == "not" ) {statusElem.innerHTML = "Неверный код активации" ;}
//statusElem.innerHTML = "Ответ сервера: "+req.responseText;
...
function get_activation() {
document .location="activ.php" ;
}

* This source code was highlighted with Source Code Highlighter .

Итог : Мошенники используют обход предупреждений через OAuth 2.0, получают пароль и email пользователя, да еще и пытаются развести на отправку sms (скорее всего используя систему подписок).