В интернет-экосистеме все более взаимосвязанных приложений, когда одно приложение хочет выполнить какое-то действие на другом приложении от имени пользователя, возникает необходимость в том, как это сделать, не делясь паролем одного приложения к другому. Распространенным примером этого является войти в Facebook приложениями, которые хотят разместить что-то в вашей Хронике или хотят получить доступ к Google Drive. Если вы делитесь своим паролем Facebook с такими приложениями, чтобы иметь доступ к вашей Хронике, и с этими приложениями происходит нарушение данных, ваши учетные данные Facebook также находятся под угрозой. Кроме того, делясь своим паролем, вы даете таким приложениям полный контроль над учетной записью Facebook вместо ограниченного доступа. Для решения этой задачи был определен протокол под названием OAuth.
Oauth
OAuth — это открытый стандартный протокол/рамка авторизации, которая позволяет приложениям получить ограниченный доступ к учетным записям пользователей другого приложения без обмена паролем. Эти приложения предоставляются с маркером авторизации, который может быть использован для использования услуг другого приложения от вашего имени без ущерба для пароля. OAuth может использоваться для авторизации приложений, API, устройств и серверов.
На высоком уровне это защищенный делегированный процесс авторизации и ограниченный доступ через HTTP, а не использование учетных данных, что сводит к минимуму риск для безопасности. Если происходит нарушение безопасности и ваши данные украдены из приложения, которое имеет доступ к вашему Facebook, ваш пароль Facebook является безопасным. Без волнений.
OAuth имеет две версии – OAuth 1.0a и OAuth 2.0. Обе версии полностью отличаются друг от друга с точки зрения спецификаций и не совместимы для совместного использования. Но OAuth 2.0 версия используется наиболее широко, и мы сосредоточимся на этом только в то время как речь идет о OAuth, если не упоминается явно.
Актеры и поток
Есть четыре актера, также называют роли, в OAuth потока.
- Владелец ресурса (пользователь) – владелец соответствующих данных, которые находятся на ресурсном сервере. Владелец ресурса разрешает доступ к учетной записи, который ограничивается объемом предоставленного разрешения.
- Ресурсный сервер (API) – Это место, где учетная запись/ресурсы пользователя размещаются в защищенной среде.
- Client (Application) – приложение, которое запрашивает доступ к учетной записи пользователя.
- Авторизация сервера (API) – Авторизация сервера выполняет проверку личности для того, чтобы выдать токен доступа.
Эти субъекты взаимодействуют друг с другом на основе протокола OAuth. Обратите внимание, что протокол OAuth связан с авторизацией, а не с аутентификацией. Общий поток протокола OAuth заключается в следующем:
- Клиент хочет получить доступ к серверу ресурсов и запрашивает разрешение у пользователя.
- Пользователь либо санкционирует запрос, либо отрицает его.
- В случае получения разрешения клиент получает разрешение.
- Таким образом, клиент представляет этот грант авторизации и его личность серверу авторизации и запрашивает токен доступа.
- Если у клиента есть и то, и другое, действительное удостоверение личности и разрешение авторизации, сервер авторизации предоставляет ему токен доступа.
- Клиент затем переходит на ресурсный сервер и запрашивает доступ к ресурсу, представляя ему токен доступа.
- Ресурсный сервер предоставляет разрешенный ограниченный доступ к клиенту только в том случае, если токен действителен.
Проблемы в мониторинге приложений с поддержкой OAuth
Реализация OAuth позволяет вашему приложению получить доступ к серверным ресурсам в других приложениях с защитой конфиденциальности и отличным пользовательским опытом. Но в то же время, OAuth создает некоторые проблемы в мониторинге вашего приложения. Давайте посмотрим на эти проблемы.
Управление токенами – Реализация OAuth требует управления токенами с государственным управлением. Это означает, что эти токены обновляются и вращаются. Если возникает ошибка авторизации, становится трудно понять, кто из авторов в протоколе OAuth виноват. Это становится кошмаром отладки.
Зависимость от запроса/ответа OAuth – Что делать, если ваш поставщик OAuth что-то изменил в своем механизме? Даже малейшее изменение в парамах запроса/ответа может нарушить все ваше приложение. Это может занять некоторое время, прежде чем понять это, если ваши разработчики не обращают внимания на новые релизы вашего поставщика OAuth.
Обратные вызовы – В зависимости от реализации для успешной транзакции OAuth может потребоваться более одного звонка API между всеми участниками. В большинстве случаев для достижения этой цели используется метод обратных вызовов, который может быть достаточно сложным, чтобы отследить, если что-то нарушается между ними. Традиционных инструментов мониторинга недостаточно для выявления ошибок обратного вызова, увеличения времени отладки и, следовательно, увеличения времени простоя.
Конфигурация – Это важно для того, чтобы сделать жизнь вашей команды DevOps легкой. Если вы используете инструмент мониторинга, который не специализируется на высококонфигурируемых задачах HTTP (S), вам будет трудно контролировать потоки OAuth, связанные с истечением/обновлением токенов и несколькими вызовами API по HTTP (s).
Решение для мониторинга приложений с поддержкой OAuth
Синтетический мониторинг является отличным выбором, когда мы имеем дело со сторонними зависимостями, HTTP (S), API REST, сложными пользовательскими путями и пользовательским механизмом входа, таким как OAuth, и т.д.
Синтетический мониторинг работает путем имитации поведения конечных пользователей с помощью пользовательских скриптов, в очень настраиваемой среде для поддержки гибкости архитектуры, а затем для упреждающего мониторинга трафика и потока. Это помогает в обнаружении и решении проблем, прежде чем реальные пользователи сталкиваются с ними. Платформа Dotcom-Monitor использует инструмент для записи сценариев, называемый EveryStep Web Recorder,для создания скриптов, которые могут имитировать пути пользователей, а также проверять содержимое, которое возвращается в ответ на конкретные действия. Для преодоления проблем мониторинга, связанных с реализацией OAuth, необходимо использовать специализированные инструменты синтетического мониторинга со следующими обязательными возможностями:
Многоступенчатый мониторинг веб-транзакций – Как мы кратко упомянули, успешная сделка OAuth является многоступенчатым процессом между ее участниками. Синтетический мониторинг дает возможность настроить многоступенчатый мониторинг для транзакций OAuth и постоянно контролировать их наличие и производительность. Многозадастный мониторинг покажет вам, какой именно шаг отвечает за сломанный поток, так что вы сможете исправить его быстро.
Пользовательские скрипты с задачами HTTP/S – Фактическая реализация OAuth отличается от приложений к приложениям в зависимости от архитектуры и политик безопасности.
Синтетический инструмент мониторинга web Services позволяет писать высококонфигурируемые задачи HTTP (ы) и пользовательские скрипты для сложных пользовательских путей. Это поможет вам отслеживать конечный поток транзакций OAuth вашего приложения и общее состояние API и обратных вызовов. Кроме того, если вам необходимо проверить данные, такие как имена пользователей, которые возвращаются в качестве ответа, вы можете настроить скрипты с EveryStep Web Recorder для проверки этих конкретных ключевых слов.
В дополнение к этим возможностям, синтетические инструменты мониторинга являются ценным активом для мониторинга сторонних зависимостей, веб-сервисов и протоколов (SOAP, REST, TCP и ICMP протоколов ), а также инфраструктуры. Dotcom-Monitor позволяет настроить многоступенчатую транзакцию для веб-API на базе OAuth с помощью http (s) задачи и непрерывно проверять время работы, производительность и функциональность 24/7.
Попробуйте полную платформу Dotcom-Monitor бесплатно в течение 30 дней.
