что такое сторонний сервис
Чаты на вебсокетах. Теперь про бэкенд
Продолжаем рассказывать про чаты на вебсокетах, но уже со стороны бэкенда. Когда-то использовали сторонний сервис, но было важно решить ряд моментов, которые он не мог покрыть. Выбирать особо не пришлось, и мы принялись разрабатывать собственное решение.
Ниже подробности о том, что было до написания кастомных чатов и какие стояли требования к реализации, из каких компонентов они состоят, как вписываются в нашу инфраструктуру и что получилось в итоге. А в конце статьи — ссылки про особенности разработки наших чатов на вебсокетах для iOS и Android.
Почему решили писать свои чаты
iFunny — приложение с лентой мемов и возможностью флуда в комментариях, но последней опции было мало по очевидным причинам. Например, людям хочется кидать мемы в личку и создавать тематические каналы. Чтобы не вынуждать их переходить в сторонние мессенджеры, мы решили сделать чаты внутри приложения.
Самый простой способ — использовать сторонний готовый сервис. На старте таким оказался Sendbird — платформа для создания чата внутри приложения, в которой есть все основные фичи современных мессенджеров. Основной плюс такого подхода:
Скорость внедрения. Как заявляет производитель, с нуля до первого сообщения — считанные минуты, так как не нужно писать бэкенд, только UI. Правда, для внутренних фич нам всё равно пришлось написать много бэкенд-кода (в основном это связано с модерацией открытых чатов и синхронизацией пользователей, а также у нас есть рейтинг открытых чатов).
Минусы, куда же без них:
Слабый контроль за происходящим внутри (пользователи доставали токен из мобильного приложения и спамили через скрипты, делали ботов).
Невозможность внутри сделать фичи под потребности.
Нельзя провести А/B-тест.
Ограничение на 500 пользователей в чате.
Для нас минусы оказались весомыми, поэтому решили разрабатывать свой чат, адаптировав под текущие задачи.
Основным техническим требованием было сделать всё то же самое, что у Sendbird, только без минусов. А также по возможности не использовать технологии, которые ещё не интегрированы в стек.
Подготовка
Выбор транспорта
Были мысли и предложения использовать UDP. Он обеспечивает более высокую скорость работы по сравнению с TCP, потому что не имеет накладных расходов на установку и на разрыв соединения. Но у нас не миллионы пользователей онлайн одновременно, а опыта работы с UDP у меня и у клиентских разработчиков было не так много, поэтому такой манёвр мог стоить неопределённого количества времени.
Для транспорта прикладного уровня выбрал WebSocket. Он давно везде поддерживается, и можно в будущем сделать чат в веб-версии приложения без правок на стороне бэкенда. А так как для установления соединения WebSocket клиент и сервер используют протокол, похожий на HTTP, можем использовать тот же механизм авторизации, что и в HTTP API приложения — через заголовок Authorization.
Выбор протокола
На ум сразу пришёл XMPP. Это открытый, основанный на XML, свободный для использования протокол мгновенного обмена сообщениями. Основными преимуществами являются децентрализация, открытость стандарта и расширяемость. Из недостатков — невысокая эффективность передачи данных за счёт XML-формата. А наличие большого количества открытых клиентов может привести к оттоку пользователей из приложения.
Из открытых XMPP-серверов самым продвинутым показался ejabberd, написанный на Erlang. На такой подвиг я был не готов, кроме того, сам по себе протокол старый, и его пришлось бы расширять под свои нужды.
Также смотрел в сторону MQTT — простого сетевого протокола, построенного по модели pub-sub. Есть возможность пустить поверх WebSocket-соединения.
До последнего думал взять MQTT, но потом наткнулся на WAMP. Это открытый протокол, который поддерживает два шаблона обмена сообщениями: pub-sub и routed RPC.
Выбор инструментов
В качестве языка был выбран Kotlin JVM, а базы данных для хранения сообщений — MongoDB. Просто потому, что это наш основной стек.
Реализация
Начал с реализации WAMP-протокола. Не найдя в открытом доступе достойных реализаций роутера на Java/Kotlin, написал свою. По сути, это движок и сердце сервера.
Далее сделал минимально функциональный прототип, где можно было публиковать и получать сообщения. На этом этапе ещё не было базы, сообщения жили в памяти до перезагрузки сервера, а функционал ограничивался созданием чата и публикацией сообщений. Но уже можно было приступать к интеграции с мобильными клиентами.
Для загрузки медиафайлов используется отдельный HTTP-эндпоинт, чтобы ничего не изобретать.
Перенос данных
В Sendbird есть механизм вебхуков. В настройках аккаунта приложения можно указать эндпоинт, и Sendbird будет слать туда информацию обо всех событиях, происходящих в приложении. Перед тем как приступить к реализации, мы сделали скрипт, который принимает такие события и складывает их в базу данных. А когда пришло время, проиграли эти события на базу данных наших чатов. Оставшиеся пробелы докачали через Platform API Sendbird по HTTP.
Отдельно можно отметить перенос медиа. Нужно было выкачать все картинки и видео, пережать их под наши стандарты и сохранить на свой S3. Процедура достаточно затратная по времени, поэтому после запуска чатов в продакшн ещё какое-то время медиа грузилось с CDN Sendbird, пока скрипты в фоне выкачивали его в наш сторадж.
Запуск
На мобильных клиентах новая реализация была спрятана за фиче-тогглом. И когда новые версии разъехались на большинство пользователей, а бэкенд был поднят, включили фичу и чаты заработали через наши сервера.
Приложение для миграции было устроено таким образом, что импортировало не только исторические данные, но и те, которые шли в реальном времени. То есть пользователи, уже использующие новый чат, могли видеть сообщения от тех, кто ещё был в Sendbird.
Архитектура бэкенда
Бэкенд состоит из двух сервисов — непосредственно сервис чатов, с которым клиент соединяется по вебсокет при переходе на вкладку «чаты» в приложении, и сервис хуков, у которого две роли:
Принимает вебхуки от чатов и делает дополнительную логику:
обновляет поисковый индекс открытых чатов;
поддерживает коллекции, необходимые для модерации;
удаляет старые каверы с S3;
считает рейтинг открытых чатов для ранжирования в приложении.
Служит HTTP-proxy для внутренних RPC-вызовов по WAMP-протоколу. Этим пользуется php-монолит для:
получения счётчика непрочитанных сообщений и инвайтов для шторки меню в приложении;
получения информации о чатах и сообщениях в админке;
асинхронной загрузки медиа в чаты.
Вместо заключения
Это то, что касается бэкенда. Про клиентскую сторону, а именно особенности разработки чатов на вебсокетах для iOS и Android можно узнать из материалов коллег, опубликованных ранее.
Там подробнее про поддержку старых версий операционных систем, способы декодирования (которые можно применить и в других задачах) и особенности работы с WAMP.
Как вести бизнес через облачные сервисы
Облачные сервисы — это онлайн-программы и другие инструменты, которые помогают удаленно управлять бизнес-процессами. За счет «облаков» компании могут автоматизировать работу, сэкономить и лучше защитить свои данные
Дарья Кугакова
Руководитель отдела маркетинга RocketSales
Что такое облачные сервисы
Облачные сервисы, или «облака», — это сеть мощных компьютеров — серверов, которые позволяют клиентам пользоваться своими ресурсами через интернет: хранить файлы и обмениваться ими, работать в онлайн-офисах, производить вычисления.
В узком смысле облачные сервисы — это онлайн-программы, которые помогают организовать удаленную работу и решать бизнес-задачи. Сотрудники получают доступ к общей базе данных из любой точки мира и могут управлять проектами. Каждый работник видит результат в реальном времени, может вносить комментарии, правки и выполнять персональные или совместные задачи. Пример облачного сервиса — Google Документы.
Облачные сервисы приходят на смену классическим «коробочным» офлайн-программам, которые устанавливают на отдельные компьютеры. Пример «коробки» — Microsoft Office.
Облачная сеть состоит из узлов хранения информации, которые называются дата-центрами. Это целые здания, заполненные огромными шкафами с серверным оборудованием. Они расположены по всему миру и связаны через интернет. Строят и обслуживают оборудование облачные провайдеры. Они же распределяют ресурсы «железных» серверов на отдельные виртуальные машины и сдают их в аренду.
Пользователи подключаются к облачным серверам через интернет и через них отправляют и получают информацию, используют программы и другие онлайн-инструменты для работы.
Кому полезны облачные сервисы
Облачные сервисы подходят для любого бизнеса — от ИП без сотрудников и стартапов до госструктур и международных корпораций.
Во время пандемии многим компаниям пришлось перейти на удаленный формат работы и использовать для этого облака.
Огромное и сложное производство работало на классических офлайн-программах. Когда началась пандемия, компьютеры остались в офисах. Сотрудники не имели к ним доступа, и работу парализовало на несколько дней. Спасти ситуацию помогло быстрое внедрение облачных программ с удаленным доступом.
Обратный пример — компании, которые уже несколько лет пользуются «облаками». Во время локдауна их сотрудники перешли на удаленку за один день, и рабочий процесс не пострадал.
За счет «облаков» компании могут автоматизировать работу и получать больше прибыли. Вот примеры того, в чем могут помочь облачные сервисы.
Настройка бизнес-процессов. Через CRM-систему менеджер получает заявку, запрашивает информацию на складе, заказывает в бухгалтерии счет и отправляет его клиенту.
Внутренняя и внешняя отчетность. Руководитель ведет учет времени и показателей работы, юристы хранят и согласовывают документы, бухгалтеры выставляют счета и отправляют налоговые декларации.
Учет товаров. Кладовщики контролируют продукцию на складе и отправляют данные менеджерам.
Коммуникация в команде. Сотрудники общаются через платформу управления проектами, корпоративную почту, мессенджеры и видеосвязь, совместно работают над документами, назначают встречи через корпоративный календарь.
«Облака» дают компаниям возможность сконцентрироваться на бизнес-процессах, а решение технических задач по настройке и поддержке офисных программ передать внешним специалистам и оплачивать по подписке.
Какие бывают облачные сервисы
Есть три типа облачных сервисов:
Частное облако принадлежит одной компании и работает на ее оборудовании. Им пользуются только сотрудники. Вся информация остается внутри, ее проще контролировать и защищать. Но частное облако могут позволить себе только крупные компании, потому что оно дорогое в использовании: нужно покупать или арендовать оборудование, самим обслуживать и администрировать его.
Публичное облако содержит и обслуживает провайдер, который сдает разным клиентам вычислительные мощности в аренду. Бизнес может закупить ровно столько ресурсов, сколько нужно для работы и хранения файлов. Это удобно и выгодно. Когда мы говорим об использовании облачных сервисов, мы чаще всего имеем в виду именно публичные облака.
Гибридное облако — когда часть работы находится в публичном облаке, а другая — в частном облаке или вообще на физических носителях. Такое бывает, например, в процессе постепенного перехода компании от традиционной инфраструктуры к облачной.
Какие задачи могут решать облачные сервисы
Глобально есть три самых популярных вида услуг, которые предоставляют облачные сервисы:
IaaS — инфраструктура как услуга, когда бизнес арендует виртуальные вычислительные ресурсы и хранилища. Например, клиент может пользоваться виртуальным компьютером на MacOS со своего Windows-устройства, чтобы использовать программы, которые есть только для Мака. При этом поддержкой и обслуживанием «железа» занимается провайдер.
PaaS — платформа как услуга. Прежде всего, это продукты для разработчиков, например программы для создания и тестирования приложений, виртуальные базы данных, системы машинного обучения и обработки больших данных.
SaaS — программное обеспечение как услуга — это готовые к использованию приложения и сервисы, не требующие установки, обслуживания и обновления со стороны пользователя. Примеры: amoCRM, Asana, Google Drive.
Для большинства бизнесов пригодятся именно SaaS — решения, потому что основная аудитория IaaS и PaaS — это системные администраторы и разработчики, а не конечные пользователи вроде менеджеров.
Облачные программы для бизнеса, которые упростят работу
CRM-система amoCRM — помогает выстраивать и контролировать поэтапную работу компании, ставить задачи менеджерам, отслеживать взаимодействия с клиентами, проводить аналитику продаж.
Платформа для управления проектами Asana — помогает распределять задачи и контролировать их выполнение, комментировать и обсуждать действия по проекту.
IP-телефония Sipuni — помогает назначить колл-центру единый многоканальный номер, записывать и анализировать разговоры, вести статистику, связать звонки с общей CRM-системой.
Пакет офисных программ Google Workspace — позволяет совместно использовать документы и другие файлы, объединить почту, календарь и другие сервисы Google в единую систему.
Тайм-трекер Time Doctor — помогает следить за рабочим временем сотрудников на удаленке, если у них оплата по часам.Интеллектуальные карты Miro и MindNode — помогают создавать прототипы, проводить креативные мозговые штурмы, рисовать схемы и шаблоны.
Графические редакторы Figma, Sketch — для дизайна, создания и обработки изображений.
Мессенджеры Skype, Zoom, Slack, Telegram, WhatsApp — для общения и переписки.
Конструкторы Tilda, WebFlow и Readymag — для создания сайтов.
Все эти программы доступны по подписке и не требуют сложного внедрения или разработки.
Зачем переходить на облачные системы
У облачных сервисов по сравнению с «коробочными» тяжело найти недостатки. У них много преимуществ:
Сборка и настройка под задачи клиента. Универсальных облачных решений нет, каждый бизнес может попробовать и сравнить разные сервисы и выбрать те, что ему больше подходят. Подключить нужные услуги и отключить ненужные можно за несколько кликов. Когда компания выберет свой набор инструментов, их можно связать в единую систему и настроить под свои нужды. Раньше интеграция могла стоить несколько миллионов рублей, но сейчас есть сервисы типа Zapier, которые помогают интегрировать что угодно быстро и недорого.
Есть виджет, который интегрирует CRM-систему с Google Диском. Менеджер может за пару кликов создать по шаблону папку клиента, заполнить ее нужными документами и отправить ссылку на нее через мессенджер — все это внутри одного окна CRM.
Постоянные улучшения. Один из главных плюсов облаков в том, что профессиональные и довольно дорогие команды аналитиков, программистов, тестировщиков и менеджеров каждый день работают над улучшением функций и удобства использования своих сервисов. Разработчики платформ думают наперед и собирают обратную связь. Даже если сейчас в наборе функций не хватает, с большой вероятностью это скоро появится.
Компании не хватало некоторых возможностей таск-менеджера Asana, и она попросила своих программистов дописать эти функции. А через пару месяцев разработчики Asana сами добавили их в очередном обновлении.
«Коробочные» сервисы, наоборот, неповоротливые, реже обновляются и хуже интегрируются между собой.
Удаленный доступ. Работать с облачными сервисами можно из любого места, где есть стабильный скоростной интернет. Несколько сотрудников могут одновременно вести задачу и видеть изменения в онлайн-режиме.
«Коробочные» программы доступны только с конкретного устройства — если сотрудник не может приехать в офис, он не сможет выполнить работу.
Экономичность. Может показаться, что пользоваться облачными сервисами дорого — нужно постоянно платить за подписку, когда коробочное решение купил — и пользуешься. Но если сравнить стоимость покупки и обслуживания «коробочных» программ с общей суммой расходов на подписку на облака — разница чаще не в пользу офлайн-решений.
«Коробочные» программы сами по себе стоят дорого, ведь вроде бы они покупаются раз и навсегда. Но в реальности их обычно нужно дорабатывать, и для этого приходится привлекать разработчиков и оплачивать их работу. Часто базовые программы не приспособлены для внедрения виджетов и сторонних обновлений — интеграции требуют много времени, а значит, много расходов на оплату часов работы программистов.
Ну и главное, на чем экономит бизнес. Провайдер покупает дорогостоящее оборудование и обслуживает его, а клиент платит только за фактическое использование виртуальных машин. Бизнесу не нужно покупать лицензии на программы, дополнительно нанимать системных администраторов и разработчиков — он платит только за ресурсы, которыми пользуется. А когда перестает пользоваться — перестает платить.
Безопасность облачных сервисов: а вдруг все удалится?
О безопасности мы решили написать отдельно: с одной стороны, это главное опасение пользователей, а с другой — еще одно преимущество облаков.
Есть мнение, что коробочные сервисы надежнее: в интернете могут украсть базу, а «коробка» установлена в компьютере, и никто туда не доберется. В реальности это не совсем так. Рассмотрим две угрозы безопасности — внешнюю и внутреннюю.
Защита облаков от внешних угроз. Провайдеры вкладывают огромные деньги в безопасность, потому что они не могут рисковать своей репутацией. Когда бизнес подключается к облачному сервису, ему гарантируют защиту и конфиденциальность информации.
Дата-центры и серверы облаков защищены от несанкционированного проникновения, перегрева, пожара и других угроз. Администраторы регулярно тестируют и обновляют оборудование, чтобы оно работало исправно и данные пользователей не пострадали.
Специалисты в области информационной безопасности постоянно проверяют систему на уязвимости и обновляют защиту с использованием эффективных и дорогостоящих технологий шифрования данных.
Небольшие компании не могут тратить столько денег на безопасность, поэтому облачная инфраструктура защищена лучше, чем данные на компьютерах в офисе.
Защита внутри компании. Облачные программы можно настроить так, что сотрудники будут видеть только те сделки и тех клиентов, с которыми они работают. Для этого есть специальные виджеты. Это повысит безопасность клиентской базы и снизит вероятность утечки информации через недобросовестного менеджера.
С помощью CRM-системы можно равномерно распределять самых платежеспособных клиентов между менеджерами, чтобы все випы не попадали к одному сотруднику, который может их увести за собой в случае увольнения.
В наборе программ Google Workspace можно за несколько кликов дать сотруднику все нужные права и доступы, например к гугл-диску и документам, и так же легко разом их закрыть, если сотрудник уволился или вызывает подозрения.
Когда бизнес ведет учет в Excel, Word, Блокноте и других подобных программах, настраивать и ограничивать доступ сотрудников сложно, а заметить кражу данных практически невозможно.
Как перейти на облачные сервисы
Переход к облачным сервисам можно разделить на несколько этапов:
Анализ и аудит. Начинать нужно с аудита и аналитики бизнес-процессов. Можно провести их самостоятельно, но лучше обратиться к профессионалам, которые знают, что нужно делать. Бизнес-аналитики и технические специалисты помогут определить, для чего стоит использовать облака, каких целей можно будет достичь, с чего стоит начинать.
Специалисты изучат бизнес-процессы, пообщаются с сотрудниками, которые будут пользоваться программами, выявят недостатки, которые мешают развитию, и на основании этого выстроят архитектуру. Начинать нужно с того, что больше всего болит, от чего компания теряет клиентов и прибыль.
Если компания пока маленькая, можно провести такой аудит самостоятельно: разложить бизнес-процессы на этапы. Для этого разберитесь:
Таких вопросов может быть гораздо больше в зависимости от сложности и специфики вашего бизнеса. Когда вы построите последовательную схему процесса, вы поймете, какие облачные сервисы могут быть вам полезны для автоматизации работы.
Выбор провайдера и специалистов по внедрению. Крупному бизнесу, использующему облачные серверы, нужен провайдер. При выборе провайдера наиболее важны три фактора: хорошая репутация, большой набор услуг и географическая близость дата-центров к целевым рынкам заказчика — это влияет на скорость работы сервисов. Например, если вы ведете бизнес в России, тяжелая база данных будет быстрее перегоняться через российские серверы, чем через американские или индийские.
Чтобы выбрать специалистов по внедрению облачных сервисов, нужно изучить их кейсы, отзывы, цены, провести переговоры и узнать о специализации исполнителя: например, лучше разрабатывает программы и виджеты, а — непосредственно внедряет решения.
Если у вас небольшой бизнес и нужно подключить всего пару облачных программ, это можно сделать своими силами или через службу поддержки самих сервисов. Например, у разработчиков ПО для магазинов цветов «Посифлора» есть отдел внедрения, который помогает клиентам разобраться в программе и правильно ее настроить.
Внедрение и обучение сотрудников. Обычно набор облачных сервисов базируется на CRM-системе, которая помогает вести продажи на всех этапах и строить долгосрочные отношения с клиентами. Она делает работу структурированной и регламентированной, позволяет учитывать все потребности и нюансы.
Клиент оставил заявку — менеджер сразу видит уведомление и берет в работу, связывается с заказчиком и последовательно двигает задачу по этапам воронки продаж. Система сама подсказывает, что делать дальше: например, «Позвоните клиенту и выявите потребность».
Важно показать сотрудникам, как облачные сервисы делают их работу проще и комфортнее. Для этого нужно разобраться в программах и научить всех правильно ими пользоваться. В таком случае сотрудники будут не просто отмечаться ради регламента, а реально пользоваться системой.
Настройка, оптимизация, интеграция. После внедрения программ нужно настроить систему работы облачных сервисов, которая будет учитывать особенности компании. Например, можно интегрировать виджет для учета рабочего времени сотрудников с платформой по управлению проектами. Настроить автоматическую отправку записей разговоров с клиентами в облачное хранилище, подключить рассылку для клиентов о степени готовности заказа через мессенджеры.
Доработка программы под задачи бизнеса. Облачную инфраструктуру нужно постоянно корректировать под текущие задачи. Например, если у компании меняется бизнес-процесс продаж, его нужно перестроить и в CRM-системе. То есть мало один раз внедрить сервис, нужно его сопровождать. Сопровождением систем занимаются те же компании, что и их внедрением.
Аутентификация и авторизация в микросервисных приложениях
Автор: Вячеслав Михайлов, Solutions Architect
Это вводная часть материала, основанного на докладе, прочитанном мной прошлым летом. Печатный материал предполагает больше информации, т.к. в одном докладе обычно не получается рассказать обо всех деталях.
Что такое аутентификация?
На процессах аутентификации и авторизации основано разделения прав доступа, без которого не обходится ни одно более или менее серьезное приложение. Поэтому понимать, как они происходили раньше и происходят теперь, очень важно, но, прежде чем углубиться в описание технологии, давайте разберемся с ключевыми терминами.
Идентификация — процесс определения, что за человек перед нами. Аутентификация — процесс подтверждения, что этот человек именно тот, за кого себя выдает. Авторизация — процесс принятия решения о том, что именно этой аутентифицированной персоне разрешается делать. То есть, это три разных, последовательных и взаимно не заменяемых понятия. Идентификацию часто подразумевают в составе аутентификации. Самое главное — четко различать аутентификацию и авторизацию.
В ходе аутентификации мы удостоверяемся, что человек, который к нам пришел, обладает доказательствами, подтверждающими личность. В этой статье речь в основном пойдет как раз об аутентификации.
Способы аутентификации
При использовании HTTP-протокола простейший способ аутентификации — Basic access authentication. В принципе этот протокол устарел и уже редко используется в интернете, особенно в незащищенных соединениях, но еще сохраняется во внутрикорпоративных системах, просто потому что некоторые из них созданы достаточно давно. Стоит разобраться, как он работает.
HTTP Basic Authentication
Первым, что при обращении к защищенному ресурсу сервер выдаст пользователю, не имеющему доступа, будет ошибка 401 Unauthorized. При этом ответ также содержит информацию о типе аутентификации (в нашем случае – Basic), который он может принимать, и контекст, в рамках которого эта аутентификация действует (Realm). Пользователь вводит логин и пароль, они упаковываются в Base64 и отправляются на сервер для проверки. Здесь существуют различные опасности. Самая распространенная — угроза man-in-the-middle attack, или атаки посредника, в ходе которой при использовании незащищенного соединения учетные данные могут перехватить злоумышленники в момент передачи от клиента к серверу или обратно.
HTTP Digest Authentication
Следующим этапом развития технологии стала чуть более сложная система HTTP digest authentication, которая исключает передачу учетных данных в открытом виде — здесь для проверки используется MD5-хеш с некоторыми примесями, что позволяет избежать подбора логина и пароля. Конечно, этот алгоритм выглядит более надежным, но и он подвержен целому ряду не самых сложных атак. Например, вот тут можно почитать об атаках более подробно.
Forms Authentication
Позднее появился процесс Forms authentication, при котором аутентификация происходит на более высоком уровне модели абстракции. HTTP-сервер при этом не сообщает об ошибке доступа, а просто перенаправляет неаутентифицированного пользователя на другую страницу. Обычно на этой странице отображаются поля для ввода логина и пароля, после заполнения которых формируется POST-запрос с данными и через защищенный канал направляется на сервер. Серверная сторона в свою очередь возвращает пользователю токен или идентификатор сессии, который сохраняется в Cookies и в дальнейшем используется для доступа к защищенному ресурсу.
Token Authentication
На схеме хорошо видно, как и в какой последовательности приложения обмениваются информацией при использовании аутентификацией по токенам.
На следующей схеме дополнительно отражены те этапы взаимодействия, в которых пользователь принимает непосредственное участие. Этот момент и является недостатком подобной схемы — нам всегда нужен пользователь, чтобы получить доступ к ресурсу.
OAuth2 & Open ID Connect
Дальнейшее усовершенствование процесса понадобилось ввиду того, что токен-аутентификация требует присутствия пользователя в момент получения доступа к защищенному ресурсу. Потому что Identity provider при передаче ему управления будет с пользователем взаимодействовать, запрашивая, например, логин и пароль.
В случае сервиса, который от имени пользователя должен через определенные промежутки времени опрашивать некий третий ресурс, — допустим, получать доступ к списку контактов в социальной сети — токен-аутентификация работать уже не будет. Дело в том, что идентификаторы сессии обычно живут очень недолго, чтобы в случае их перехвата злоумышленники получили доступ к сервису лишь на ограниченное время. Но из-за короткого срока действия токена не хватает, например, на ночной процесс.
В 2006 году в ходе работы над реализацией протокола Open ID для Twitter обнаружилась потребность в новом открытом протоколе авторизации. В 2007 инженеры Google и AOL начали совместную работу над ним, а в 2009 Twitter предложил своим пользователям решение, делегировавшее сторонним сервисам доступ к аккаунтам и основанное на протоколе OAuth. Три года спустя была опубликована новая версия — OAuth 2, упростившая разработку клиентских приложений и получившая целый ряд новых возможностей, среди которых оказалось и обновление токена без участия пользователя. Многие сервисы начали использовать этот протокол еще до его официального утверждения.
Разбираемся детально ху из ху
OpenID 1.0 (2006) & OpenID 2.0 (2007) позволяли приложению(арб) запрашивать у доверенного сервера (authority) проверку пользователя(user). Отличия между версиями для нас несущественны.
Взгляд сверху
Обычно в системах встречаются разные компоненты: пользователи, работающие через браузер, пользователи, взаимодействующие с сервером через мобильные приложения, и просто серверные приложения, нуждающиеся в принадлежащих вам данных, хранящихся на других серверах, доступ к которым осуществляется через Web API.
Single sign-on — технология единого входа — позволяет пользователю переключаться между различными приложениями без повторной аутентификации. Используя SSO можно избежать множественных логинов, так что пользователь просто не будет замечать этих переключений. При этом ситуации, когда в рамках вашей инфраструктуры таких приложений будет больше одного, встречаются постоянно. Технология единого входа особенно удобна в больших энтерпрайз-системах, состоящих из десятков приложений, слабо связанных между собой. Вряд ли пользователи будут довольны, вводя логин и пароль при каждом обращении к системе учета рабочего времени, корпоративному форуму или внутренней базе документов.
В качестве реализации мы рассматриваем протокол OAuth2. В принципе, существуют и другие, например, Kerberos, успешно взаимодействующий с Windows, но в случае гетерогенной сети, в которой существуют компьютеры, использующие и Windows-, и Mac-, и UNIX-системы, использовать проприетарные протоколы зачастую неудобно. Тем более, это касается случаев, когда доступ к вашим сервисам осуществляется через веб — здесь OAuth2 оказывается лучшим кандидатом.
На рисунке выше показано, какие именно протоколы используются при каждом типе взаимодействия.
Как мы знаем из раздела «разбираемся детально ху из ху», OpenID Сonnect нужен, чтобы получить у пользователя его учетные данные и проверить их. OAuth 2.0 нужен, чтобы получать токены доступа и с ними обращаться к ресурсам.
Терминология OAuth2 & OpenID Connect
Сервис выдачи токенов
Open ID Connect Provider — важнейший объект всей конструкции централизованного сервиса аутентификации, он также может называться Security Token Service, Identity Provider authorization server и т. д. Различные источники называют его по-разному, но по смыслу это сервис, который выдает токены клиентам.
Клиент
Client — устройство или программа (браузер, приложение), которым требуется либо токен для аутентификации пользователя, либо токен для доступа к какому-то ресурсу (подразумевается, что данный ресурс «знаком» с тем конкретным «Security Token Service» у которого клиент запрашивает токен для доступа).
Пользователь
User — собственно конечный пользователь — человек.
Область (scope)
Scope — идентификатор ресурса, к которому клиент хочет получить доступ. Список scope посылается в адрес сервиса выдачи токенов в составе запроса на аутентификацию.
По умолчанию все клиенты имеют возможность запрашивать любые области, но это можно (и нужно) ограничивать в конфигурации сервиса выдачи токенов.
Scopes бывают двух видов:
Запрос на аутентификацию
Authentication/Token Request — процесс запроса аутентификации.
Токен личности
Identity Token — подтверждение аутентификации. Этот токен содержит минимальный набор информации о пользователе.
Токен доступа
Access Token — информация, что конкретному пользователю разрешается делать. Клиент запрашивает Access Token и затем использует его для доступа к ресурсам (Web APIs). Access Token содержит информацию о клиенте и пользователе, если она присутствует. Важно понимать, что есть такие типы авторизации, при которых пользователь в процессе непосредственно не участвует (подробнее об этом в следующей части)
Токен обновления
Refresh Token — токен, по которому STS вернет новый Access Token. В зависимости от режима работы, Refresh Token может быть многоразовым и одноразовым. В случае с одноразовым токеном, при запросе нового Access Token будет также сформирован готовый Refresh Token, который следует использовать при повторном обновлении. Очевидно, что одноразовые токены более безопасны.
Более подробно о составе токенов в разделе «структура токена».
Процесс аутентификации
При обращении пользователя к клиенту, тот перенаправляет пользователя на Open ID Connect Provider, который запрашивает у пользователя логин и пароль. В случае успешного прохождения проверки параметров аутентификации он возвращает назад identity token и access token, с которыми пользователь может обращаться к защищенному ресурсу.
Структура токена
Формат
В реализации OAuth2 используется так называемый jwt-токен, который состоит из трех частей. Допустим, при обращении к Identity provider вы отправляете логин/пароль и в ответ получаете токен. Он будет включать в себя: Header (заголовок), Payload (контент) и Signature (подпись). На сайте jwt.io его можно декодировать и посмотреть содержимое формате JSON. На этом сайте вы также найдете описание правил формирования jwt-токенов.
В том, что токены в процессе обмена передаются незашифрованными, ничего страшного нет. Мы изначально исходим из предположения, что коммуникация происходит по защищенному HTTPS-каналу, и повторное шифрование токена было бы избыточным. Единственное, в чем нам нужно убедиться – то, что токен не был подменен или сфальсифицирован на клиентской стороне, для этого достаточно иметь подпись и проверять ее на сервере. Кроме того, токен не содержит никакой критически важной информации.
Кроме identity tokens, есть еще и аccess tokens, которые содержат информацию о выданных пользователю клеймах. Срок действия access token достаточно короткий, потому что его хищение может обеспечить несанкционированный доступ к ресурсу. Т. е. злоумышленник, если ему удастся заполучить токен этого типа, доступ получит на очень непродолжительное время. Для получения нового access token используется refresh token, который обычно не фигурирует в незащищенных средах, в частности в режиме доступа из браузера он вообще не используется. Какие именно токены будут возвращены клиенту в процессе аутентификации, разберемся в следующей части.
Основные поля
Кратко остановимся на том, какие есть стандартные полях в токене и зачем они нужны:
Заключение первой части
В этой статье мы постарались дать теоретический и терминологический фундамент, который понадобится нам создании работающего решения в следующих статьях.
Минимальная реализация интеграция Identity Server в ваше приложение выглядит так:
Минимальная реализация интеграции веб-клиента с Identity Server:
Минимальная реализация интеграции веб-API с Identity Server: