По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Вы наверняка слышали об опасностях разглашения своих паролей и почему этого делать не стоит. Существуют различные протоколы, предназначенные для вашей защиты и которые избавят вас от необходимости повторного ввода ваших паролей или учетных данных. Когда веб-сайт требует ввести пароль для получения доступа, он может воспользоваться техникой под названием OAuth для того, чтобы упростить задачу.
Цель этой статьи – показать вам, как веб-сайт или приложение принимают запросы на вход от пользователей, которые их посещают. У этих платформ есть необходимые полномочия? Есть ли у них право подтверждать вашу личность и получать доступ к некоторым вашим данным от вашего имени? OAuth объясняет весь этот процесс и помогает его упростить. Прочитайте статью до конца, чтобы узнать, как онлайн-проверки стали автоматизированными и как так получилось, что для их завершения требуется всего один клик.
Что такое OAuth?
OAuth – это протокол авторизации открытого стандарта, который можно добавить в приложения, чтобы позволить пользователям получать безопасный доступ к их платформе. Например, с помощью этого протокола вы можете указать приложению Facebook разрешить ESPN.com доступ к вашим сообщениям и обновлениям в социальных сетях без обязательного раскрытия ваших учетных данных. Такой доступ позволяет существенно снизить риск. Если на ESPN.com вдруг произойдет утечка данных, то информация, которой вы владеете в Facebook, будет защищена.
OAuth работает, не обмениваясь паролями с другими платформами. Вместо этого он просто отправляет им маркеры авторизации. Этот маркер используется для подтверждения личности пользователя. Это ключевая стратегия, которой пользуются клиенты и поставщики услуг. Проще говоря, эта концепция представляет собой протокол аутентификации, который позволяет платформам и поставщикам услуг взаимодействовать, не выдавая при этом свои пароли.
Примеры OAuth
Один из распространенных примеров протокола OAuth связан с большинством устройств Android. Когда вы покупаете смартфон Android, то вам необходимо войти в свою учетную запись электронной почты, чтобы получить доступ к большинству функций телефона.
Когда вы вошли в свою электронную почту в телефоне, то вам понадобиться некоторая информация для доступа к другим приложениям или веб-сайтам. Принципы OAuth позволяют пользователям мгновенно обмениваться своими учетными данными электронной почты с платформой. Вам не потребуется вводить пароль, но при этом веб-сайт позволит вам аутентифицироваться и получить доступ.
Существует множество других примеров и вариантов использования протокола OAuth, которые демонстрируют его концепцию. И это при условии, что вы можете обмениваться своими учетными данными для получения информации на разных платформах без повторного ввода пароля.
Хорошим примером здесь может послужить ситуация, когда вас перенаправляют на другой веб-сайт, и вы получаете сообщение с текстом «Эй, вы хотите получить доступ к нашему сайту с учетными данными другого сайта?» Давайте условно назовем веб-сайт, запрашивающий доступ пользователя, получателем, а платформу, на которой вы в данный момент вошли в систему, - отправителем. Когда вы пытаетесь войти на сайт-получатель, вам необходимо будет узнать, заходите ли вы на сайт под тем же именем, что и на сайте-отправителе.
Facebook – один из наиболее распространенных примеров платформ, которые используют данный протокол. Когда вы используете приложение на Facebook, оно запросит доступ к информации и фотографиям вашего профиля. В таком случае Facebook является отправителем ваших данных для получения доступа и изображений. Приложение здесь является получателем, и как пользователь вы намерены пользоваться услугами принимающей платформы. Нажимая кнопку «Разрешить», вы предоставляете получателю доступ к вашим изображениям, а OAuth существенно упрощает весь этот процесс.
Некоторым вашим умным домашним устройствам, таким как телевизору, системе безопасности, тостеру и т.д., требуется вход в систему, чтобы вы могли управлять ими через браузер или мобильное устройство. Эти устройства работают на, так называемой, конфиденциальной авторизации OAuth, и они надежно хранят ваши учетные данные. Таким образом, вам не требуется вводить свои учетные данные на различных терминалах веб-сайта.
Как работает OAuth?
Реальность такова, что OAuth был разработан с целью фокусировки внимания на авторизации, а не на аутентификации. Авторизация предполагает получение разрешения на выполнение определенных действий. А вот аутентификация предполагает доказательство того, то вы являетесь лицом, которое имеет необходимый доступ к информации, защищенной в профиле. OAuth не запрашивает аутентификацию пользователя, а просто разрешает доступ к другим приложениям и ресурсам.
Хороший способ рассмотреть принцип работы этого протокола – это провести аналогию с ключом камердинера. Такой ключ предназначен для того, чтобы дать камердинеру доступ к управлению вашим автомобилем, но при этом он не обязательно позволит ему открыть багажник. Токен OAuth предназначен для использования в качестве служебного ключа для вашего смарт-устройства. Как пользователь вы можете контролировать информацию, которая будет использоваться на разных платформах. Вы можете вручить ключ камердинера каждому получателю, но у них все равно не будет ключа полного доступа или доступа к конфиденциальных данным, которые скрыты в профиле.
В абсолютно любой транзакции OAuth участвуют 3 основные стороны: пользователь, отправитель и получатель. Эти 3 стороны в шутку можно назвать любовным треугольником OAuth. Мы рассмотрим несколько простых шагов для того, чтобы проиллюстрировать то, как OAuth обеспечивает защиту аутентификации для пользователей на разных платформах.
Шаг 1: пользователь показывает свое намерение получить доступ
Шаг 2: получатель получает разрешение. Учетные цифровые идентификационные данные будут отправлены вместе с этим разрешением, которые будут использоваться для выявления подделки и проверки источника запроса на права доступа.
Шаг 3: пользователь перенаправляется к поставщику услуг или отправителю.
Шаг 4: пользователь дает разрешение.
Шаг 5: получатель получает маркер доступа.
Шаг 6: получатель получает доступ к защищенному ресурсу.
SAML vs OAuth
Многие люди очень легко могут указать на сходства между SAML и OAuth, но их концепции все же очень разные. SAML, также известный как язык разметки утверждений безопасности, представляет собой альтернативный стандарт проверки личности пользователя, который многие организации используют для поддержки функций системы единого входа (SSO). SAML – это функция, позволяющая организациям контролировать тех, кто отвечает за корпоративные ресурсы.
Между SAML и OAuth есть множество различий. SAML использует XML для отправки сообщений, а OAuth – технологию JSON. OAuth разработан для того, чтобы упростить работу с мобильными устройствами, а SAML – для обеспечения повышенного уровня безопасности. Последнее различие является основным. OAuth в основном полагается на API. Именно поэтому многие мобильные приложения, современные веб-сайты, игровые приставки и Интернет вещей используют данный протокол. Как правило, OAuth предлагает пользователям больше возможностей. Чтобы провести аутентификацию пользователя, SAML сбрасывает cookie сессию в браузере пользователя, которая позволяла человеку получать доступ к определенным веб-страницам. Такой вариант отлично подходит для краткосрочного доступа, но не очень подходит для случаев, когда вам необходимо входить в сеть многократно.
OpenID vs OAuth
Если говорить простым языком, то OpenID используется для аутентификации, а OAuth – для авторизации.
OpenID поддерживает интегрированную аутентификацию. Это означает, что он поддерживает сторонние приложения для поддержки и аутентификации пользователей при попытке использовать уже имеющиеся учетные записи. В то же время, OAuth был разработан для того, чтобы вам не приходилось вводить свои учетные данные для входа в сторонние приложения.
Оба протокола могут использоваться для выполнения похожих задач, но это вовсе не означает, что они взаимозаменяемы. OpenID обеспечивает подтверждение личности, в то время как OAuth имеет более общее направление использования. Когда клиент использует OAuth, сервер выдает маркер доступа третьей стороне, этот маркер используется для доступа к защищенному ресурсу, а источник проверяет этот маркер. Здесь еще стоит обратить внимание на то, что личность владельца маркера не проверяется.
Сравнение
SAML 2.0
OAuth2
OpenID Connect
Что это?
Открытый стандарт аутентификации и авторизации
Открытый стандарт авторизации
Открытый стандарт аутентификации
Основное назначение
SSO для корпоративный приложений
API-авторизация
Поддержка сторонних приложений
SSO для корпоративных приложений
Формат
XML
JSON
JSON
OAuth 1.0 vs OAuth 2.0
OAuth 2.0 призван полностью улучшить работу OAuth 1.0. Эти два похожих фреймворка просто несопоставимы. Если вы сейчас создаете новое приложение или веб-сайт, то убедитесь, что они основаны именно на OAuth 2.0. Большинство современных веб-сайтов уже перешли на OAuth 2.0, потому что OAuth 1.0 просто-напросто обесценился.
Последнюю версию, OAuth 2.0, проще и быстрее реализовать в приложениях и на веб-сайтах. OAuth 1.0 был разработан с учетом криптографических требований, а также он не поддерживал более трех потоков и даже масштабирование.
OAuth 2.0 разработан так, что он поддерживает целых шесть потоков, которые в свою очередь поддерживают различные приложения и требования. Этот протокол аутентификации позволяет использовать подписанные учетные идентификационные данные через HTTPS. Токены OAuth не нужно шифровать при отправке из одного места в другое, поскольку они шифруются непосредственно при передаче.
Как OAuth защищает API?
Защитить API можно с помощью API Connect. OAuth – это специальный протокол авторизации, который делает доступными сторонние веб-сайты и приложения без регистрации учетных данных пользователя или личной информации.
Сценарий пользователя OAuth
Люди, использующие API Connect совместно с этим протоколом, используют несколько методов для защиты своего API. Вот некоторые доступные варианты:
Создание API поставщика OAuth. API поставщика будет содержать токены OAuth для обеих конечных точек потока OAuth.
Защита API с помощью определения безопасности OAuth. Когда вы добавляете определение безопасности этого протокола в свое приложение или на веб-сайт, то вы добавляете настройки, которые позволяют вам контролировать операции API с помощью стандарта авторизации OAuth.
URL-адрес метаданных OAuth и URL-адрес аутентификации. Вы можете установить URL-адрес метаданных OAuth или URL-адрес аутентификации, который будет использоваться для получения пользовательского контента с веб-сайта. К нему будет установлен доступ с удаленного сервера, и он будет добавлен в маркер доступа или как часть полезных данных, содержащих маркер безопасности.
Ответы OAuth
Во время выполнения процесса OAuth 2.0 API Connect дает различные ответы на запросы.
Устранение неполадок OAuth
Если у вас возникли какие-либо проблемы с данным протоколом, то вы можете устранить неполадки самостоятельно. Перейдите на портал разработчиков и форумы на Youtube, Github и DeveloperWorks.
В основном, в современных корпоративных сетях можно выделить следующие типы задержки:
Задержка обработки: Это время, которое затрачивает маршрутизатор на получение пакета на входном интерфейсе и отправку его в исходящую очередь на исходящий инетерфейс. Задержка обработки зависит от следующих факторов:
Скорость центрального процессора;
Использование центрального процессора;
Архитектура маршрутизатора;
Настроенные опции входящих и исходящих интерфейсов.
Задержка очереди: Это время, которое пакет находится в очереди на отправку. Данный вид задержки зависит от таких факторов как количество и размер пакетов, которые уже находятся в очереди, полоса пропускания интерфейса и механизм очередей;
Задержка сериализации: Время, необходимое для перемещения фрейма в физическую среду передачи;
Задержка распространения: Время, которое занимает путь пакета от источника к получателю по каналу связи. Эта задержка сильно зависит от среды передачи.
Методы ограничения задержки
Маршрутизатор имеет достаточно мощностей для того, чтобы быстро и оперативно принимать решения о дальнейшем перенаправлении пакетов. Задержка обработки, очереди и сериализации зависит от следующих факторов:
Средняя длина очереди;
Средняя длина пакетов в очереди;
Пропускная способность канала связи.
Указанные ниже методы удовлетворяют требования чувствительного к задержке трафика
Увеличение пропускной способности: При достаточной пропускной способности, сокращается время ожидания в исходящей очереди, тем самым, сокращается задержка сериализации;
Приоритизация чувствительного к задержкам трафика: Данный метод является более гибким. Указанные ранее алгоритмы PG, CQ, MDRR и LLQ имеют значительное воздействие задержку, вносимую очередью;
Сжатие поля полезной нагрузки: Сжатие поля полезной нагрузки уменьшает общий размер пакета, тем самым, по сути, увеличив пропускную способность канала передачи. Так как сжатые пакеты меньше обычных по размеру, их передача занимает меньше времени. Важно помнить, что алгоритмы сжатия весьма сложны, и компрессия наряду с декомпрессией могут добавить дополнительные задержки;
Сжатие заголовков пакетов: Сжатие заголовков не так сильно требует ресурсов центрального процессора, как сжатие поля полезной нагрузки, поэтому, данный механизм часто используется наряду с другими алгоритмами уменьшения задержки. Сжатие заголовков особенно актуально для голосового трафика.
Потеря пакетов
Обычно, потеря пакетов происходит при условии переполнения буфера маршрутизатора. Например, пакеты находятся в исходящей на интерфейсе очереди. В какой-то момент размер очереди достигает своего максимума, и, новые приходящие пакеты просто отбрасываются. В целом, потеря пакетов происходит по следующим причинам:
Потеря на входящей очереди: если не хватает мощности CPU (Central Processing Unit) маршрутизатора, пакеты могут быть потеряны еще на входящем интерфейсе;
Игнорирование пакетов: Буфер маршрутизатора переполнен, следовательно, приходящие пакеты просто игнорируются;
Ошибка во фреймах: Аппаратное обнаружение ошибок во фреймах, например, Cyclic Redundancy Check (CRC).
Как правило, потеря пакетов является результатом чрезмерной загрузки интерфейса.
Используются следующие методы и алгоритмы для предотвращения потерь пакетов:
Увеличение пропускной способности чтобы предотвратить перегрузку на интерфейсе;
Обеспечение достаточной пропускной способности и увеличение буферного пространства для гарантированного перемещения чувствительного к задержкам трафика в начало очереди;
Ограничить перегрузку путем отбрасывания пакетов с низким приоритетом до того, как произойдет переполнение интерфейса. Для обеспечения данной цели, инженер может использовать алгоритм Weighted Random Early Detection (WRED), который будет случайно отбрасывать нечувствительный к потерям и трафик и пакеты, с заранее настроенными низкими приоритетами.
Система автоматического исходящего обзвона – это программное обеспечение, с помощью которого любой Call-центр может в разы сократить время и затраты на исходящий обзвон. Существует 4 основных способа организовать обзвон списка номеров:
ручной набор - оператор делает набор вручную. Это неэффективное расходование времени оператора (набор номер, писк контакта в базе и так далее);
preview – диалер загружает списки контактов, в которых оператор заранее видит информацию по каждому клиенту и принимает решение о звонке самостоятельно. При этом, он не набирает номер телефона и не снимает трубку до того момента, как абонент ответит на звонок;
progressive – так же, как и в preview загружаются списки контактов, но в этом варианте у оператора нет возможности отказаться от внешнего звонка. Диалер стремится занять звонками максимальное количество доступных каналов. Это подходит для автоматических извещений, IVR (когда вызываемого абонента нужно подключить на интерактивное меню) и прозвона номеров;
predictive dialer – самое интересное. При предиктивном дозвоне используются сложные сценарии и реальный математический расчет. Dialer предназначен для максимального сокращения времени ожидания оператором звонка при минимальных потерях успешных звонков. Для этого используются алгоритмы, «просчитывающие» необходимое количество звонков в следующий момент на основании данных о количестве операторов, которые будут доступны на момент соединения, о средней длительности разговора (ACD), о проценте успешных соединений (ASR) и прочих. У каждого продукта данные секретны и не публичны :).
Хочу презентацию продукта!
Программный продукт IqDialer
В качестве основной телекоммуникационной платформы для IqDialer был выбран Asterisk. Дайлер кроссфункционален и стабилен – он справляется с разными задачами, а его надежность протестирована в десятках инсталляций. Все функциональные возможности диалера (интеграция с внешними компонентами, CRM, например) управляются посредством RESTful API.
Работает это примерно так: устанавливается и настраивается оборудование, необходимое для начала работы Call-центра, затем загружается база контактов для обзвона, и операторы входят в систему, занимая свои виртуальные рабочие места и вставая в очередь на телефонии. IqDialer определяет доступные ресурсы для работы, и в этот момент программа начинает расчеты, запрашивает статистику звонков, рассчитывает, сколько нужно взять лидов (контактов для обзвона), занимает расчетное количество операторов, трансформирует лиды в звонки и отправляет все на телефонию. Первый этап закончен :)
В следующем этапе звонки, попавшие в телефонию, при дозвоне до клиента попадают в очередь и диалер собирает всю доступную ему информацию о звонке. На основании собранной информации программа отправляет карточки лидов операторам, и те видят на своих экранах всю информацию по контакту и обрабатывают звонок в соответствии с поставленной задачей. На последнем этапе по завершению звонка, оператор дополнительно обрабатывает карточку лида, сохраняя ее (срабатывает интеграция CRM и диалера) дает понять системе сколько длилась дообработка и что оператор готов принять новые вызовы (освобождается в очереди). Система обрабатывает завершенный звонок, производя манипуляции с лидом, меняет его статус и создает задачи для пропущенного звонка.
«Под капотом» это выглядит примерно так:
Время статистики. Для сравнения эффективности различных режимов набора, мы возьмем 3 (три) самых распространенных варианта обзвона (Preview, Progressive и Predictive), которые практикуют Call - центры, и для примера возьмем Call – центр, где один оператор работает 5 дней в неделю, по 8 часов в день:
Действие
Preview
Progressive
Predictive
Поиск карточки клиента (сек)
0
0
0
Ознакомление с карточкой клиента (сек)
10
0
0
Набор номера (сек)
0
0
0
Дозвон (сек)
20
20
0
Занятость оператора в разговоре (сек)
90
90
90
Всего времени на звонок (сек)
120
110
90
Звонков в день
240
262
320
Формула получения звонков в день и месяц
8*60*60/120240*22
8*60*60/110262*22
8*60*60/90320*22
Звонков в месяц
5280
5764
7040
Если привести здесь в качестве примера статистику, учитывающую еще и ручной набор, то результатом сравнения будет превосходство предиктивного набора над ручным почти в 2 раза. Даже при таком простом анализе, который не учитывает множество дополнительных факторов и полностью исключает сравнение с ручным набором оператором телефонных номеров, очевидна выгода :)
Таким образом, основываясь на вышесказанном, любой Call - центр просто обязан использовать только Predictive (предиктивный) Dialer. Однако не все так просто. Этот режим эффективен в том случае, если число работающих операторов не опускается ниже 20–30. В противном случае predictive dialing вместо пользы будет приносить только вред.
Смешанный режим работы оператора
В работе каждого Call - центра случаются временное затишье или резкий всплеск количества обращений, которые тяжело прогнозировать. В такой ситуации действенным инструментом поддержания необходимого и достаточного уровня сервиса могут стать работа в смешанном режиме – blended Agent. Смешанный режим позволяет оператору обрабатывать входящие и исходящие обращения по различным каналам коммуникаций в рамках единой очереди.
Чтобы проиллюстрировать выгоду, полученную при добавлении исходящих звонков в кейс (рабочие задачи) оператора, можно привести такой пример: допустим, операторы принимают только входящие звонки и при этом в течение одного рабочего дня простаивают 20% своего времени. Тогда в течение дня оператор не работает (8*60*0.2) = 96 минут. Пусть в Call - центре работает 10 операторов, тогда легко вычислить, что колл-центр уже простаивает (96*10/60) = 16 часов в день , а в месяц уже (16*22) = 352 человеко-часа.
При этом, у колл-центра могут быть заказы на проведение опросов (исходящая кампания на обзвон), и во время простоя оператору будут подмешиваться звонки с опросами. Производительность и качество обслуживание входящих звонков останутся на должном уровне, а Call - центр получит дополнительную прибыль.
Есть определенные тонкости, которые необходимо учитывать при планировании кампаний исходящего обзвона и входящих звонков, дело в том, что смешанный колл-центр будет эффективно работать только в режимах preview и progressive. Поскольку режим predictive подразумевает 100% занятость и любые отвлечения оператора приведут к потерям клиентов.
IqDialer: интерфейс и как он выглядит
Посмотрите, как выглядит дашборд супервизора, который следит за компаниями исходящего обзвона:
Двигаемся к отчетности – ниже отчет агентов по статусам (включает круговую диаграмму):
Заказать продукт
Отчеты реального времени – кто говорит, сколько времени:
Можно посмотреть самую важную информацию по каждой очереди:
Тайм – лайны! Смотрим, что делал наш агент на протяжении отрезка времени – звони, говорил, делал пост – ворк (работа после звонка) и так далее:
Интересен продукт? Напишите нам на dialer@merionet.ru