В результате этого клиентское приложение, использующее AdWords API, может получить доступ к аккаунту AdWords без адреса электронной почты и пароля пользователя.
Чтобы создать учетные данные OAuth2, выполните перечисленные ниже действия.
Во-первых, нужно определить тип приложения , которое вы хотите создать. В AdWords API существует два типа приложений:
С помощью приведенной ниже таблицы определите нужный тип приложения.
| Что нужно выбрать | Ситуация |
|---|---|
| Устанавливаемое приложение (рекомендуется) |
|
| Веб-приложение |
|
Определив тип приложения, нажмите на соответствующую вкладку ниже и следуйте инструкциям по созданию идентификатора и секретного кода клиента.
Устанавливаемое приложение
Следуя приведенным ниже инструкциям, настройте использование учетных данных OAuth2 с клиентской библиотекой вашего языка.
Примечание. Если вы решите не использовать одну из наших клиентских библиотек, вам потребуется реализовать процессы для или самостоятельно.Альтернативный вариант создания учетных данных OAuth2 состоит в использовании OAuth2 Playground . В сочетании с Google API Console эта система позволяет самостоятельно создавать токены OAuth2.
Система OAuth2 Playground предназначена для тех пользователей, которым нужен доступ к аккаунтам только для одного управляющего аккаунта или пользователя AdWords. Если вам необходимо запрашивать учетные данные для нескольких пользователей, тогда лучше использовать клиентские библиотеки, как описано выше.
Поскольку у вас уже есть токен обновления , вам больше не нужно использовать OAuth2 Playground в качестве разрешенного URI перенаправления. Чтобы удалить эту систему из списка, выполните следующие действия:
Итак, у вас есть учетные данные OAuth. Теперь можно осуществлять запросы AdWords API и использовать для требуемой клиентской библиотеки.
В этом разделе описывается порядок доступа к AdWords API с использованием сервисных аккаунтов.
Сервисный аккаунт – это аккаунт, принадлежащий приложению, а не отдельному конечному пользователю. Сервисные аккаунты обеспечивают взаимодействие между веб-приложением и сервисом Google. Ваше приложение вызывает API от имени сервисного аккаунта без прямого вовлечения пользователей.
AdWords API разрешает доступ сервисного аккаунта через домены G Suite .
В сервисном аккаунте реализован процесс OAuth2, в котором вместо авторизации пользователя применяется файл ключа, доступный только вашему приложению.
Применение сервисных аккаунтов дает два существенных преимущества:
Сервисные аккаунты широко применяются для обеспечения программного доступа к API по протоколу OAuth2 без вмешательства пользователя.
Однако настроить такие аккаунты для работы с AdWords API непросто. Более простой альтернативой является с сохраняемым токеном обновления. Такой подход позволяет приложению в любой момент запрашивать новые токены доступа.
В рамках этого процесса требуется настроить авторизацию приложения через клиентскую библиотеку в соответствии с описанной выше . Это нужно сделать лишь один раз, поскольку срок действия токенов обновления Google OAuth2 неограничен.
Во-первых, необходимо создать ключ служебного аккаунта в Google API Console.
Поскольку управление G Suite осуществляется на уровне домена, необходимо надежно защитить файл ключа, который обеспечивает доступ авторизованных аккаунтов к сервисам Google. Это особенно важно в связи с тем, что мы предоставляем аккаунту сервиса возможность олицетворять любого пользователя домена.
Кроме того, рекомендуется предоставлять каждому аккаунту сервиса доступ только к одному API Google. Для этого используется поле scope , которое описывается в следующем разделе. Такая профилактическая мера позволяет ограничить объем данных, открытый для несанкционированного доступа в случае компрометации файла ключа.
Чтобы предоставить сервисному аккаунту возможности олицетворения, выполните следующие действия:
Теперь вы можете осуществлять доступ к аккаунту AdWords с использованием сервисного аккаунта в рамках процесса утверждения 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 , чтобы обеспечить связь учетных данных с требуемым аккаунтом. Кроме того, задача обновления должна вовремя их обновлять. После подключения нового аккаунта может потребоваться ее запустить.
Наконец, в многопоточных приложениях необходимо распределять объект учетных данных только между потоками, работающими в аккаунте, с которым он связан.
Токен доступа может предоставлять разную степень доступа к данным. Изменяемый параметр scope (область действия) определяет набор ресурсов и операций, к которым токен предоставляет доступ. Во время запроса токена доступа ваше приложение отправляет в параметр scope одно или несколько значений.
Ниже представлены текущая и устаревшая область действия для AdWords API.
Клиентское приложение, использующее AdWords API, обычно запрашивает автономный доступ. Это может произойти в том случае, если приложению необходимо запустить пакетные задания, когда пользователь просматривает ваш сайт без подключения к Интернету.
Устанавливаемые приложения используют автономный доступ по умолчанию.
Заголовок 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
Заботясь о своих клиентах, команда сервиса Invola реализовала прямое подключение к почте по технологии OAuth 2.0.
В этой статье мы расскажем что это такое, как это работает и как влияет на безопасность данных пользователя.
Мы опустим ряд технических моментов, донося суть технологии простым и понятным для рядовых пользователей языком.
Постоянные пользователи сервиса знают, как порой было неудобно использовать дублирующий email , часто забывая отправлять на него очередное письмо. Мы получали письма с просьбой пересмотреть алгоритм получения счетов и коммерческих в пользу прямого подключения к почте.
По прошествии пары недель плодотворной работы программиста и специалиста по безопасности алгоритм авторизации внедрен и теперь является основным способом подключения клиентов к сервису.
Что такое OAuth?
Если говорить сухим техническим языком, то это протокол авторизации, позволяющий выдать одному сервису (в данном случае Invola) права на доступ к ресурсам пользователя на другом сервисе (доступ к почте).
У пользователя больше оснований доверять приложению, поскольку пользователь может быть уверен, что несанкционированный доступ к его личным данным невозможен. Не владея логином и паролем пользователя, приложение сможет выполнять только те действия с данными, которые разрешил пользователь , и никакие другие.
Говоря проще, можно сказать так: сервис Invola подключается к вашей почте для получения счетов и коммерческих предложений, при этом не требуя логин и пароль, а запрашивая право на доступ. Если вы подтверждаете – приложение получает доступ до тех пор, пока он не будет отозван самим пользователем, либо пока приложение вообще существует и активно.
В коммуникации между Invola и почтовым сервером используется токен доступа access token (шаг 4-5), который автоматически устаревает через час и обновляется по необходимости (автоматически, без участия пользователя, программным обеспечением Invola).
Теперь поговорим о безопасности, и почему авторизация по OAuth предпочтительнее, чем по логину-паролю .
Когда вы предоставляете любому сервису логин и пароль для доступа к аккаунту (mail.ru, gmail.com), вы фактически предоставляете пароль от всей учетной записи (таким образом можно получить доступ, например, к диску, фотоальбомам и другим личным данным).
Предоставляя доступ через OAuth вы сами выбираете, к каким ресурсам аккаунта вы даете доступ . То есть, пользователь сам контролирует к каким ресурсам он готов дать доступ. Рассмотрим пример запрашиваемых прав при подключении к Invola:
"Просмотр и управление почтой " - для автоматического получения счетов и КП, "просмотр адреса " – для получения e-mail ящика, "просмотр профиля " – для получения имени пользователя (требуется на этапе регистрации).
К сожалению, не все почтовые сервера (включая корпоративные) поддерживают авторизацию по технологии OAuth , в частности популярный сервис Яндекс.Почта. Если у вас почта находится на яндексе, подключиться к нашему сервису в данный момент можно только используя логин-пароль.
Немного о безопасности .
Мы очень хорошо понимаем, насколько критичным для бизнеса является утечка конфиденциальных данных или несанкционированный доступ к данным о клиентах, финансовых операциях, личной переписке. Безопасность данных – один из главных приоритетов нашей работы .
Токены доступа, равно как и пароли для доступа к почте, хранятся на защищенном выделенном сервере баз данных с использованием криптографической схемы на основе динамических ключей.
В итоге стоить отметить, что наши сотрудники не имеют доступ к почтовым серверам и переписке наших пользователей ни при каких условиях.
Все коммуникации между пользователем и сервисом, а также между сервисом и почтовым сервером осуществляются по защищенному каналу SSL , иными словами все передаваемые данные в обе стороны шифруются стойким криптографическим алгоритмом.
Если у вас есть бизнес, вы отправляете много счетов и коммерческих предложений своим клиентам, то вы просто обязаны попробовать нашу систему. Invola отправляет автоматические оповещения , если по счету небыло ответа, а также отслеживает реакцию ваших покупателей на счета (дорого, долгий срок поставки и др.). В результате вы получаете прирост к доле оплаченных счетов , а также имеете возможность собирать статистику эффективности работы ваших менеджеров, частым причинам отказов.
|OAuth 2 – это протокол авторизации, который предоставляет приложениям ограниченный HTTP-доступ к учетным записям пользователей. Он передаёт аутентификацию пользователей сервису, на котором размещены учетные записи, и авторизует сторонние приложения и передаёт им доступ к учетной записи пользователя. OAuth 2 обеспечивает авторизацию веб-приложений и мобильных устройств.
Данное руководство ознакомит вас с ролями OAuth 2, типами авторизации, с потоками и случаями использования OAuth 2.
В OAuth существует четыре роли:
Рассмотрим каждую роль подробнее.
Владельцем ресурса является пользователь, который проходит аутентификацию в приложении, чтобы получить доступ к своей учетной записи.
Приложение ограничивает доступ к учетной записи пользователя с помощью полномочий (то есть, прав на выполнение того или иного действия: чтения, записи и т.п.).
Сервер ресурсов хранит защищенные учетные записи пользователей, а сервер авторизации проверяет учётные данные пользователя, а затем выдает токены доступа к приложению.
С точки зрения разработчика приложений, API сервиса выполняет роли сервера ресурсов и сервера авторизации. В дальнейшем мы будем ссылаться на эти роли как на сервис или API.
Клиент – это приложение, которое хочет получить доступ к аккаунту пользователя. Прежде чем оно сможет сделать это, пользователь должен авторизоваться в приложении, а API должен подтвердить авторизацию.
Роли OAuth взаимодействуют между собой следующим образом:
Прежде чем вы сможете использовать OAuth в приложении, вам необходимо зарегистрировать приложение. Это делается через регистрационную форму в разделе Developer или API на веб-сайте сервиса, где нужно предоставить следующую информацию:
После регистрации приложения сервис предоставит вам учётные данные приложения, которые можно найти в поле client identifier и client secret. Client ID – это общедоступная строка, которая используется API сервиса для определения приложения; также с её помощью создаются URL-ы авторизации. Client Secret позволяет API сервиса подтвердить подлинность приложения, когда оно запрашивает доступ к аккаунту пользователя. Эти конфиденциальные данные хранятся между приложением и API.
Полномочия авторизации зависят от метода, используемого приложением для запроса авторизации, а также от типов полномочий, поддерживаемых API. OAuth 2 определяет четыре вида полномочий, каждый из которых полезен в различных случаях:
Код подтверждения – самый распространённый тип полномочий, оптимизированный для приложений серверной стороны, в которых исходный код закрыт, а Client Secret недоступен посторонним. Этот поток основан на редиректе, а это означает, что приложение должно иметь возможность взаимодействовать с агентом пользователя (т.е. веб-браузером пользователя) и получать коды авторизации API, которые направляются через агента пользователя.
Поток с кодом подтверждения выглядит так:
Поток неявного доступа используется мобильными приложениями или веб-приложениями, где конфиденциальность client secret гарантировать нельзя. Этот поток также основан на редиректе, но токен доступа получает агент пользователя, после чего он передаётся приложению. Таким образом он может быть виден пользователю или другим приложениям на устройстве пользователя. Кроме того, этот поток не выполняет проверку подлинности приложения, для этого используется URI (который был зарегистрирован в сервисе).
При неявном доступе токены обновления не поддерживаются.
Поток неявного доступа в основном работает следующим образом: пользователю предлагается авторизоваться в приложении, сервер авторизации передает токен доступа агенту пользователя, который передает его приложению. Подробнее этот процесс выглядит так:
Данный тип подразумевает, что пользователь передаёт учётные данные непосредственно приложению, которое с их помощью получает токен доступа. Этот тип должен поддерживаться только на сервере авторизации. Кроме того, его следует использовать только в случае, если приложению можно доверять (например, оно принадлежит сервису или операционной системе пользователя).
Получив учётные данные пользователя, приложение запрашивает токен доступа у сервера авторизации. Если учётные данные правильные, сервер авторизации предоставит токен доступа. Авторизация завершена.
Этот тип предоставляет приложению возможность подключиться к собственному аккаунту сервиса. Такой поток полезен, если приложение хочет обновить свое зарегистрированное описание или redirect URI или получить доступ к другим данным, хранящимся в учетной записи сервиса.
Приложение запрашивает токен доступа, отправляя свои учетные данные, client ID и client secret. . Если учётные данные правильные, сервер авторизации предоставит токен доступа. Авторизация завершена.
Получая токен доступа, приложение может использовать его, чтобы получить доступ к аккаунту пользователя через API.
Если токен валидный, API обрабатывает запрос. Если токен недействителен, API выдаст ошибку invalid_request.
После того, как действие токена доступа истечет, API выдаст ошибку invalid_request. Если при вместе с токеном доступа приложение получило токен обновления, сейчас оно может использовать его, чтобы запросить новый токен доступа на сервере авторизации.
Теперь вы знакомы с основами OAuth 2.
Tags: ,OAuth 2 представляет собой фреймворк для авторизации, позволяющий приложениям осуществлять ограниченный доступ к пользовательским аккаунтам на HTTP сервисах, например, на Facebook, GitHub и DigitalOcean. Он работает по принципу делегирования аутентификации пользователя сервису, на котором находится аккаунт пользователя, позволяя стороннему приложению получать доступ к аккаунту пользователя. OAuth 2 работает в вебе, на десктопных и мобильных приложениях.
Эта статья предназначена для разработчиков приложений и предоставляет обзор ролей, типов авторизации и типичных сценариев использования OAuth 2.
Начнём с ролей OAuth!
OAuth определяет четыре роли:
Владельцем ресурса является пользователь , который авторизует приложение для доступа к своему аккаунту. Доступ приложения к пользовательскому аккаунту ограничен "областью видимости" (scope) предоставленных прав авторизации (например, доступ на чтение или запись).
Сервер ресурсов непосредственно хранит защищённые данные аккаунтов пользователей, а авторизационный сервер проверяет подлинность информации, предоставленной пользователем , а затем создаёт авторизационные токены для приложения , с помощью которых приложение будет осуществлять доступ к пользовательским данным.
С точки зрения разработчика приложения API сервиса одновременно выполняет и роль сервера ресурсов и роль сервера авторизации. Далее мы будем считать эти две роли одной, и называть её Сервис или API .
Клиентом является приложение , которое хочет осуществить доступ к аккаунту пользователя . Перед осуществлением доступа приложение должно быть авторизовано пользователем, а авторизация должна быть одобрена со стороны API.
Теперь, когда у нас есть представление о ролях, используемых в OAuth, рассмотрим диаграмму их взаимодействия друг с другом.
Рассмотрим описание последовательности шагов на этой диаграмме:
Фактический порядок шагов описанного процесса может отличаться в зависимости от используемого типа разрешения на авторизацию, но в целом процесс будет выглядеть описанным образом. Далее мы рассмотрим различные типы разрешений на авторизацию.
Перед тем, как начать использовать OAuth в вашем приложении, вам необходимо зарегистрировать своё приложения в сервисе. Это делается путём регистрации в разделе "developer" или "API" сайта сервиса, где вам необходимо предоставить следующую информацию (возможно, включая некоторые детали о вашем приложении):
Redirect URL - это URL, на который сервис будет перенаправлять пользователя после авторизации (или отказа в авторизации) вашего приложения.
После регистрации приложения сервис создаст учётные данные клиента - идентификатор клиента (client ID) и секрет клиента (client secret). Идентификатор клиента представляет собой публично доступную строку, которая используется API сервиса для идентификации приложения, а также используется для создания авторизационных URL для пользователей. Секрет клиента используется для аутентификации подлинности приложения для API сервиса, когда приложение запрашивает доступ к аккаунту пользователя. Секрет клиента должен быть известен только приложению и API.
В абстрактном описании протокола выше первые четыре шага касаются вопросов создания разрешения на авторизацию и токена доступа. Тип разрешения на авторизацию зависит от используемого приложением метода запроса авторизации, а также от того, какие типы разрешения поддерживаются со стороны API. OAuth 2 определяет четыре разных типа, каждый из которых полезен в определённых ситуациях:
Код авторизации является одним из наиболее распространённых типов разрешения на авторизацию, поскольку он хорошо подходит для серверных приложений , где исходный код приложения и секрет клиента не доступны посторонним. Процесс в данном случае строится на перенаправлении (redirection), что означает, что приложение должно быть в состоянии взаимодействовать с пользовательским агентом (user-agent), например, веб-браузером, и получать коды авторизации API, перенаправляемые через пользовательский агент.
Опишем процесс на диаграмме:
Если пользователь выбирает "Авторизовать приложение", сервис перенаправляет пользовательский агент (браузер) по URL перенаправления (redirect URL), который был задан на этапе регистрации клиента (вместе с кодом авторизации ). Ссылка будет выглядеть похожим образом (в данном примере приложение называется "dropletbook.com"):
Приложение запрашивает токен доступа у API путём отправки авторизационного кода и аутентификационной информации (включая секрет клиента ) сервису. Ниже представлен пример POST-запроса для получения токена DigitalOcean:
Теперь приложение авторизовано! Оно может использовать токен для доступа к пользовательскому аккаунту через API сервиса с заданными ограничениями доступа до тех пор, пока не истечёт срок действия токена или токен не будет отозван. Если был создан токен для обновления токена доступа, он может быть использован для получения новых токенов доступа, когда истечёт срок действия старого токена.
Неявный тип разрешения на авторизацию используется мобильными и веб-приложениями (приложениями, которые работают в веб-браузере), где конфиденциальность секрета клиента не может быть гарантирована. Неявный тип разрешения также основан на перенаправлении пользовательского агента, при этом токен доступа передаётся пользовательскому агенту для дальнейшей передачи приложению. Это, в свою очередь, делает токен доступным пользователю и другим приложениям на устройстве пользователя. Также при этом типе разрешения на авторизацию не осуществляется аутентификация подлинности приложения, а сам процесс полагается на URL перенаправления (зарегистрированный ранее в сервисе).
Процесс выглядит следующим образом: приложение просит пользователя авторизовать себя, затем сервер авторизации передаёт токен доступа к пользовательскому агенту, который передаёт токен приложению. Далее мы опишем процесс в деталях.
При неявном типа разрешения на авторизацию пользователю предоставляется ссылка, запрашивающая токен у API. Эта ссылка выглядит почти так же, как ссылка для предыдущего способа (с кодом авторизации), за исключением того, что запрашивается токен вместо кода (обратите внимание на response type "token"):
Когда пользователь нажимает на ссылку, он должен сперва осуществить вход в систему для подтверждения своей личности (если он, конечно, ещё не залогинен). После этого сервис предложит пользователю авторизовать или отказать в авторизации приложению для доступа к аккаунту пользователя. Пример такого диалога представлен ниже:
Пользовательский агент следует по URI перенаправления, сохраняя при этом токен доступа.
Приложение возвращает веб-страницу, которая содержит скрипт для извлечения токен доступа из полного URI перенаправления, сохранённого пользовательским агентом.
Пользовательский агент запускает скрипт извлечения токена доступа, а затем передаёт извлечённый токен приложению.
Теперь приложение авторизовано! Оно может использовать токен для доступа к пользовательскому аккаунту через API сервиса с заданными ограничениями доступа до тех пор, пока не истечёт срок действия токена или токен не будет отозван.
При этом типе разрешения на авторизацию пользователь предоставляет приложению напрямую свои авторизационные данные в сервисе (имя пользователя и пароль). Приложение, в свою очередь, использует полученные учётные данные пользователя для получения токена доступа от сервиса. Этот тип разрешения на авторизацию должен использоваться только в том случае, когда другие варианты не доступны. Кроме того, этот тип разрешения стоит использовать только в случае, когда приложение пользуется доверием пользователя (например, является частью самого сервиса, или операционной системы пользователя).
После того, как пользователь передаст свои учётные данные приложению, приложение запросит токен доступа у авторизационного сервера. Пример POST-запроса может выглядеть следующим образом:
Внимание: DigitalOcean в настоящее время не поддерживает тип разрешения на авторизацию с использованием учётных данных владельца ресурса, поэтому ссылка выше ведёт на воображаемый авторизационный сервер "oauth.example.com".
Тип разрешения на авторизацию с использованием учётных данных клиента позволяет приложению осуществлять доступ к своему собственному аккаунту сервиса. Это может быть полезно, например, когда приложение хочет обновить собственную регистрационную информацию на сервисе или URI перенаправления, или же осуществлить доступ к другой информации, хранимой в аккаунте приложения на сервисе, через API сервиса.
Приложение запрашивает токен доступа путём отправки своих учётных данных, своего идентификатора клиента и секрета клиента авторизационному серверу. Пример POST-запроса может выглядеть следующим образом:
Внимание: DigitalOcean в настоящее время не поддерживает тип разрешения на авторизацию с использованием учётных данных клиента, поэтому ссылка выше ведёт на воображаемый авторизационный сервер "oauth.example.com".
После того, как приложение получит токен доступа, оно может использовать этот токен для доступа к пользовательскому аккаунту через API сервиса с заданными ограничениями доступа до тех пор, пока не истечёт срок действия токена или токен не будет отозван.
Ниже представлен пример запроса к API с использованием curl . Обратите внимание, что он содержит токен доступа:
Если токен доступа валиден, API обработает полученный запрос. Если срок действия токена доступа истёк или токен некорректен, API вернёт ошибку "invalid_request".
После истечения срока действия токена доступа все запросы к API с его использованием будут возвращать ошибку "Invalid Token Error". Если при создании токена доступа был создан и токен для обновления токена доступа (refresh token), последний может быть использован для получения нового токена доступа от авторизационного сервера.
Ниже представлен пример POST-запроса, использующего токен для обновления токена доступа для получения нового токена доступа:
На этом мы завершаем наш обзор OAuth 2. Теперь у вас есть общее представление о том, как работает OAuth 2, а также о том, когда и как использовать существующие типы разрешения на авторизацию.
Если вы хотите узнать больше об OAuth 2, рекомендуем ознакомиться со следующими статьями.
Существует множество способов распространения вредоносного спама во ВКонтакте. Но вредители не дремлют, в их головы приходят все больше интересных идей. И оказалась как никак кстати. Мошенники научились пользоваться им для обхода страницы предупреждения о вредоносных сайтах.
А все началось с того, что однажды на моей стене появилось такое сообщение:
Из любопытства перешел по ссылке и попал на очередной фишинговый сайт. Но мне показалась странной сама ссылка, она имела вид (половина символов в ASCII):
vkontakte.ru/away.php ?to
=http%3A%2F%2FApi.vKontakte.Ru%2F%2Fo%2561u%2574%…
Что означает каждый из параметров:
В этом и заключается весь смысл обхода блек-листа вредоносных сайтов ВКонтакте. Появляется только алерт о переходе на 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 .
