Сквозная авторизация через OAuth 2.0: как мы объединили 6 сервисов на «1С-Битрикс»

Проблема: 6 сервисов — 6 авторизаций

На момент нашего прихода на проект там было 6 сервисов на «1С-Битрикс». У каждого — своя авторизация. В прошлой статье мы в немного задевали авторизацию.

Что это означало на практике:

• Пользователь регистрировался и входил в каждый сервис отдельно.

• Клиентская база дублировалась или рассинхронизировалась.

• Не было единого понимания, кто есть кто: один и тот же клиент в разных сервисах мог иметь разные данные.

• Поддержка не могла увидеть полную картину по пользователю.

Бизнес решил: нужна единая точка авторизации на отдельном приложении.

Архитектор выбрал для этого Laravel. В этот момент к проекту подключились мы.

Архитектура: единый сервис авторизации + 6 сервисов на «Битрикс»

Мы спроектировали систему, где:

• Сервис авторизации на Laravel — единая точка входа для всех пользователей.

• 6 сервисов на «1С-Битрикс» — получают авторизацию через OAuth 2.0.

• Технические пользователи для API — созданы для каждого «Битрикс»-сервиса.

Зачем нужны технические пользователи

Для каждого «Битрикс»-сервиса мы создали пользователя для технического обмена по API. Он решал несколько задач:

• Получение доступов пользователей — по ролевой модели, о которой мы рассказывали в предыдущей статье.

• Внутренние обмены — синхронизация данных между сервисами.

• Единый пользователь для авторизации клиентов — чтобы клиент мог войти в любой сервис через общую точку входа.

Как работает сквозная авторизация

Сценарий для клиента и внутреннего пользователя:

1. Пользователь авторизуется на сервисе авторизации.

2. Видит меню выбора сервисов — список доступных ему систем.

3. Выбирает нужный сервис.

4. Через OAuth 2.0 попадает в него.

5. В шапке сервиса выводится набор доступных сервисов — чтобы можно было перейти в другой сервис напрямую, минуя меню на стороне приложения авторизации.

Всё работало штатно. Но затем мы обнаружили проблему.

Проблема: задержка при авторизации

После того как «Битрикс»-сервисы получили сквозную авторизацию, выяснилось: есть задержка при входе в сервис, когда пользователь уже авторизован.

Мы проанализировали все обмены и нашли причину. «Битрикс»-сервисы получали два больших объекта:

1. Объект клиента

Со всеми нужными коллекциями и связями. Чем больше данных о клиенте — тем больше объект — тем дольше передача по сети.

2. Объект со всеми сервисами

Перечень всех сервисов с названиями, описаниями и кодом SVG-изображений. Код SVG хранился на сервисе авторизации, и каждый раз передавался в «Битрикс»-сервис, чтобы вывести иконки сервисов в шапке.

Время передачи: пара секунд. Для бизнеса это было критично.

Решение: сократить объекты

Мы оптимизировали оба объекта.

Что сделали:

• Объект клиента — сократили до необходимого минимума. Убрали лишние коллекции и связи, оставили только то, что реально нужно «Битрикс»-сервису для работы.

• Объект сервисов — убрали код SVG. Вместо встроенного кода теперь передаётся ссылка на SVG. Картинка подгружается отдельно, а не тащится в основном объекте.

Результат: задержка ушла. Авторизация стала быстрой.

Новый вызов: гостевые сервисы

Всё работало хорошо. Но есть гостевые сервисы — например, Маркет.

Сценарий:

• Клиент заходит на Маркет без авторизации.

• Наполняет корзину.

• Хочет оформить заказ — и тут нужна авторизация.

Как было бы без доработки:

1. Клиент идёт на сервис авторизации.

2. Авторизуется.

3. Ищет среди доступных сервисов Маркет.

4. Снова идёт на корзину.

Слишком долго и неудобно. Клиент мог просто уйти.

Решение: система внутренних редиректов

Мы сделали систему внутренних редиректов для таких сценариев.

Как это работает:

1. Пользователь на гостевом сервисе нажимает на кнопку авторизации.

2. В ссылку добавляется GET-параметр текущей страницы — откуда идёт нажатие.

3. Пользователь попадает на сервис авторизации.

4. Сервис авторизации считывает GET-параметр.

5. После авторизации происходит редирект на ту страницу, где был пользователь.

Результат: клиент вернулся туда, где был, — и может продолжить оформление заказа.

Новый нюанс: прямые ссылки на файлы

Проблема с гостевыми сервисами решилась. Но появился новый нюанс.

Сценарий:

• Неавторизованному пользователю приходит ссылка на файл — акт, счёт, документ.

• Без авторизации он не может его скачать.

• И не понимает, куда идти, чтобы найти этот файл.

Решение: отдельный сценарий для выдачи файлов

Мы сделали отдельный сценарий для выдачи файлов.

Как это работает:

1. Мы добавили GET-параметр service — чтобы понимать, откуда пришёл клиент.

2. Клиент нажимает на ссылку.

3. Идёт на авторизацию.

4. Авторизуется.

5. Мы по API обращаемся к нужному сервису, запрашиваем документ.

6. Выдаём его ресурсом клиенту — и он может скачать файл.

Результат: клиент получает свой документ, даже если ссылка пришла ему на почту, а он не был авторизован.

Итог: не просто OAuth, а сценарии для бизнеса

Мы не только внедрили логику сквозной авторизации через OAuth 2.0, но и доработали механизм редиректов для различных сценариев бизнеса:

• быстрый вход в сервисы без задержек;

• возврат на исходную страницу после авторизации;

• выдача файлов по прямым ссылкам.

Всё это — чтобы упростить жизнь клиенту.

Стек

• Сервис авторизации: Laravel (PHP)

• Сервисы: «1С-Битрикс»

• Авторизация: OAuth 2.0

• Обмен данными: API, JSON

Что мы вынесли из этой истории

1. Сквозная авторизация — это не только OAuth

OAuth 2.0 решает задачу входа. Но реальные сценарии — гостевые сервисы, прямые ссылки на файлы — требуют доработки механизма редиректов.

2. Оптимизация обменов — критична

Пара секунд задержки может показаться мелочью. Но для бизнеса это критично. Сокращение объектов и замена SVG на ссылки — простые решения с большим эффектом.

3. Думайте о госте

Не все пользователи авторизованы. Гостевые сценарии — это то, что часто забывают, но именно там теряются клиенты.

4. Прямые ссылки — отдельный сценарий

Ссылка на файл, пришедшая на почту, — это отдельный путь пользователя. Его нужно проектировать отдельно, а не надеяться, что пользователь «как-то разберётся».

Заключение

Эта история — про то, что сквозная авторизация — это не просто внедрить OAuth и забыть. Это работа со сценариями: быстрый вход, возврат на страницу, гостевые корзины, прямые ссылки на файлы.

Мы прошли этот путь и доработали механизм редиректов для разных бизнес-сценариев. Клиент авторизуется один раз — и попадает туда, куда ему нужно.