В данной статье мы рассмотрим систему аутентификации пользователей и внешних систем в личном кабинете через сервер аутентификации Blitz Identity Provider.
Согласно требованиям проекта, который мы рассмотрим здесь в качестве примера, взаимодействие клиентской и серверной частей должно происходить по Rest API, реализованном на микрофреймворке Slim. Для авторизации пользователей необходимо провести интеграцию с сервером аутентификации Blitz Identity Provider, который в свою очередь интегрирован с внутренней системой единого входа заказчика (SSO). Это мастер-система, определяющая возможность доступа и уровень доступа пользователя для личного кабинета является Blitz. Поэтому при каждой авторизации пользователя в системе обновляется уровень доступа по данным из Blitz.
Данные в личный кабинет должны приходить из систем хранения информации (ERP и SRM) и управления учетными записями пользователей, также использующие Rest Api Личного кабинета. Эти системы должны проходить аутентификацию напрямую в ЛК.
Описание системы Blitz Identity Provider и протокола авторизации OAuth 2.0
Blitz Identity Provider реализует более простой доступ к системам заказчика и бесшовное переключение между различными приложениям. Этому способствуют технологии однократной аутентификации и единого входа (Single Sign-On), а также работа с механизмами аутентификации устройств доступа пользователей.
Blitz Identity Provider предлагает разные варианты аутентификации — это привычная парольная аутентификация, различные способы двухфакторной аутентификации (OAuth 2.0), использование смарт-карт и ключей с электронной подписью.
Краткое описание протокола авторизации OAuth 2.0
OAuth 2.0 — протокол авторизации, который позволяет дать системе (приложению) права на доступ к данным пользователя в другой системе. Протокол избавляет от необходимости доверять приложению логин и пароль, а также позволяет выдавать ограниченный набор прав, а не все сразу.
OAuth 2.0 базируется на возможностях базовых web-технологий: HTTP-запросах, редиректах. Поэтому применение OAuth возможно на любой платформе с доступом к сети и браузеру: на сайтах, в мобильных и desktop-приложениях.
Общая схема работы приложения, использующего OAuth, такова:
получение авторизации
обращение к защищенным ресурсам
Результатом авторизации является access token — некий ключ (обычно просто набор символов), предъявление которого является пропуском к защищенным ресурсам. Обращение к ним в самом простом случае происходит по HTTPS с указанием в заголовках или в качестве одного из параметров полученного access token'а.
В протоколе описано несколько вариантов авторизации, подходящих для различных ситуаций:
авторизация для приложений, имеющих серверную часть (чаще всего, это сайты и веб-приложения)
авторизация для полностью клиентских приложений (мобильные и desktop-приложения)
авторизация по логину и паролю
восстановление предыдущей авторизации
Схема работы протокола авторизации OAuth 2.0
Схема работы личного кабинета с Blitz
Проверка токена авторизации
При заходе пользователя в личный кабинет react-приложение проверяет, есть ли в куках браузера пользователя access_token. Если токен присутствует, то front отправляет запрос на back для получение нужных ему данных, передавая в параметре или в заголовках access_token.
Если на запрос react-приложения, back отдает 401 ответ (то есть действие токена закончилось либо токен некорректный), front отправляет новый http запрос на обновление access_token. Back приложение пытается обновить access_token с помощью refresh_token, делая запрос в Blitz. Если обновление прошло успешно, то на front возвращается новый access_token, который записывается в куки.
Если access_token не найден в системе (БД back приложения) или срок жизни refresh_token закончился или access_token отсутствует в куках, то фронт начинает процедуру авторизации.
Процедура авторизации
Сначала со стороны react-приложения отправляется запрос на back-приложения для получения адреса страницы системы Blitz, чтобы перенаправить туда пользователя для авторизации.
В системе Blitz сотрудник вводит свои учетные данные, авторизуется по номеру телефона или по сеансу ОС, если находится во внутренней сети заказчика.
При успешном прохождении процедуры авторизации на стороне Blitz пользователь перенаправляется на личный кабинет с get параметром code по адресу, указанному в параметрах, при переходе в Blitz.
Front-приложение делает запрос на back с параметром code, полученным из Blitz. Далее back-приложение отправляет http-запрос с параметром code в Blitz для получения токенов доступа и времени их жизни. После этого back-приложение отправляет еще один http-запрос в Blitz, передавая в параметрах полученный access_token, для получения информации о сотруднике.
При успешном получении информации о сотруднике из Blitz система (back-приложение личного кабинета) проверяет для пользователя внутри системы учетная запись и при ее наличии обновляет информацию о сотруднике, а при отсутствии создает новую УЗ.
Затем ID УЗ сотрудника и информации о токенах доступа записывается в БД, а на фронт отдается access_token.
На этом процедура авторизации сотрудника в системе через Blitz заканчивается.
Аутентификация react-приложения в системе
Описание механизма авторизации внутри системы
Получение токена доступа react-приложением от back-приложения описано в разделе “Схема работы с blitz”.
После получения токена front-приложение передает в каждом запросе на back этот токен параметром либо в заголовках запроса. Так происходит до тех пор пока не истечет срок хранения токена в куках, либо от back не вернется код ответа 401, что будет означать окончание действия токена и станет сигналом для его обновления.
Схема взаимодействия react-приложения с back-приложением
Аутентификация внешних систем
Схема взаимодействия внешних систем с личным кабинетом
Всем внешним системам для взаимодействия с личном кабинетом по rest api выдается логин и пароль (client_id и client_secret).
В bitrix создается пользователь с этими данными и привязывается к соответствующей группе доступа.
Для получения токена доступа система отправляет пару логин/пароль на определенный адрес back приложения личного кабинета. Back приложение личного кабинета проверяет, есть ли в bitrix пользователь с такими данными. Если пользователь найден, то формируется и отдается токен доступа для системы. Если же пользователь не найден, то выдается ошибка авторизации.
С помощью полученного при авторизации токена, внешняя система может делать запросы на разрешенные для ее уровня доступа адреса rest api личного кабинета.
После окончания время жизни токена (получения 401 ответа от back приложения личного кабинета) должна заново пройти процедуру авторизации.
Заключение
Выбранный стек технологий для реализации проекта и наличие системы единой авторизации у заказчика породило необходимость реализации “двойной авторизации”: авторизации web-приложения личного кабинета в blitz и авторизации react-приложения для работы с back по Rest Api.
В рамках выполнения задачи была разработана и реализована схема, позволяющая учесть требования и особенности устройства единой системы авторизации заказчика.
