Пакеты PHP для аутентификации и прав доступа для реальных B2B-ролей

Почему B2B-роли быстро превращаются в хаос

В B2B-приложении редко бывает одна понятная роль «администратор». Большинству компаний нужен свой список пользователей, свои правила и свои границы аккаунта. Один и тот же email может принадлежать двум клиентским аккаунтам и означать в каждом из них совершенно разное.

Именно поэтому простые системы ролей быстро начинают ломаться. Один человек может быть покупателем в одной команде, утверждающим лицом в другой и контактным лицом по биллингу сразу для обеих. Если ваше приложение умеет проверять только «админ это или нет» или «менеджер это или нет», оно пропустит главный вопрос: админ чего именно и для какой компании?

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

Ещё один слой добавляет доступ для поддержки. Внутренним сотрудникам иногда нужно зайти в аккаунт, чтобы исправить проблему, проверить шаг настройки или посмотреть, почему сломалась синхронизация. Такой доступ должен быть узким и временным. Специалисту поддержки часто нужен только доступ на чтение, возможно, одно действие вроде повторного запуска задачи и автоматическое время окончания. Полные админские права проще реализовать, но они очень быстро создают риски.

Именно поэтому пакеты PHP для аутентификации и прав доступа важнее в B2B-продуктах, чем в простом приложении для обычных пользователей. Вы не просто назначаете роли. Вы моделируете участие в командах, исключения, временный доступ и правила делегирования, которые соответствуют тому, как компании реально работают.

Небольшой пример хорошо показывает проблему. В одном SaaS-аккаунте Мария владеет рабочим пространством, Бен управляет счетами, а Приия отвечает за онбординг клиентов. Приия должна приглашать пользователей, но не должна видеть выгрузки по зарплатам. Бен должен смотреть счета, но не удалять проекты. Марии не стоит каждый день втягиваться в обе задачи. Если модель прав не может выразить это понятно, ошибки начнутся очень рано.

Что сравнить перед выбором

Многие команды начинают с входа в систему и вспоминают о правилах доступа только тогда, когда у продукта уже есть клиенты. В B2B-разработке это обычно не работает, потому что один человек может принадлежать компании, иметь роль и при этом всё равно иметь ограничения на то, что он может менять.

Начните с разделения аутентификации и авторизации. Вход отвечает на вопрос «кто этот пользователь?». Авторизация отвечает на вопрос «что этот пользователь может делать прямо сейчас?». Некоторые пакеты закрывают обе задачи, но делают это не одинаково хорошо. Когда вы сравниваете пакеты PHP для аутентификации и прав доступа, проверьте, даёт ли пакет понятные проверки прав или только поток входа с добавленной сверху таблицей ролей.

Участие в компании важно не меньше, чем роли. В SaaS пользователь редко бывает просто «администратором» или «участником». Он может быть администратором внутри одной компании, контактным лицом по биллингу в другой или гостем только на чтение в одном рабочем пространстве. Если пакет считает роли глобальными, потом вы можете упереться в неудобную модель данных.

Хороший пакет должен помогать легко отвечать на такие вопросы:

• Может ли один пользователь принадлежать нескольким компаниям или командам?
• Могут ли роли жить внутри этого участия, а не только в записи пользователя?
• Можно ли проверять доступ к отдельной записи через политики или voter'ы?
• Может ли админ приглашать, удалять, блокировать или переназначать других пользователей без полного доступа ко всей системе?

Правила на уровне записей заслуживают отдельного внимания. В B2B-приложениях часто нужны проверки вроде «можно редактировать счета только своей компании» или «можно видеть сделки только своего региона». Такие правила лучше держать в политиках или voter'ах, а не размазывать по контроллерам и шаблонам. Так логика остаётся в одном месте, и баги легче заметить.

Делегирование админских прав — это место, где многие пакеты отлично выглядят в демо и проваливаются в продакшене. Нужны чёткие правила: кто может приглашать пользователей, кто может менять роли и кто может удалить последнего владельца компании. Если этот процесс кажется неудобным уже при чтении документации, после запуска он будет ощущаться ещё хуже.

Простой тест помогает быстро понять ситуацию: представьте, что владелец компании приглашает менеджера, менеджер приглашает подрядчика, а подрядчик должен видеть только один проект. Если пакет умеет выразить это без лишней боли, скорее всего, он вам подходит.

Пакеты для Laravel, которые стоит рассмотреть

Среди пакетов PHP для аутентификации и прав доступа у Laravel есть несколько надёжных вариантов, но они решают разные задачи. Один пакет может хорошо закрывать вход в систему, а другой — помогать с участием в командах или точными проверками прав.

Spatie Laravel Permission — самый безопасный старт для многих B2B-приложений. Он хорошо работает, когда модель доступа понятная и стабильная: роли вроде Owner, Admin, Billing и Support, плюс именованные права вроде manage users или view invoices. Он также хорошо сочетается с Laravel gates и policies, так что глобальные роли можно держать в одном месте, а проверки на уровне записей — в политиках.

Это делает Spatie хорошим вариантом для делегирования админских прав. Если владельцу нужно дать руководителю финансов доступ к биллингу, но не к настройкам продукта, пакет справится с этим аккуратно. Если у вашего приложения рано появляются сложные правила для тенантов, вам, возможно, понадобится дополнительное планирование того, как хранить контекст компании или команды.

Laratrust больше подходит, когда участие в командах в SaaS — часть приложения с самого начала. Пользователь может принадлежать к нескольким командам и иметь в каждой из них разную роль. Звучит как мелочь, но потом это сильно экономит нервы. В B2B-продуктах один и тот же человек часто выступает администратором в одном клиентском аккаунте и пользователем только на чтение в другом.

Bouncer лучше подходит, когда одних ролей уже недостаточно. Он делает упор на abilities, и это удобно, когда проверки прав зависят от владения или правил модели. Например, продавец может редактировать только свои сделки, а руководитель команды — любые сделки внутри той же компании. Если ваше приложение постоянно спрашивает «кому принадлежит эта запись?», Bouncer часто легче подстроить под такую логику.

Laravel Fortify — это другой класс решений. Он отвечает за вход, сброс пароля, подтверждение email, двухфакторную аутентификацию и похожие auth-потоки. Полной системы прав доступа он не даёт, поэтому вам всё равно понадобятся политики, роли или и то и другое.

Jetstream помогает, если вы хотите готовую отправную точку для учётных записей и команд. Поддержка teams может заметно сократить время на настройку, особенно для приглашений и переключения между командами. Но Jetstream не заменяет правила прав доступа. Обычно его используют вместе с политиками и часто вместе со Spatie или Bouncer.

Удобно думать о разделении так:

• Используйте Fortify для аутентификации.
• Используйте Jetstream, если команды — часть оболочки продукта.
• Используйте Spatie для понятных наборов ролей и прав.
• Используйте Laratrust, когда роли внутри команды — основа приложения.
• Используйте Bouncer, когда правила владения встречаются повсюду.

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

Варианты для Symfony и других фреймворков

Symfony даёт очень серьёзную основу для управления доступом, когда простых проверок ролей уже недостаточно. Среди пакетов PHP для аутентификации и прав доступа это один из лучших вариантов для проверки политик, потому что компонент Security подталкивает к понятным правилам, а не к россыпи if-ов.

Самая сильная сторона — система voter'ов. Voter позволяет ответить на один конкретный вопрос в коде, например: «Может ли этот менеджер аккаунта редактировать эту запись клиента?» или «Может ли этот администратор команды пригласить нового пользователя в это рабочее пространство?». Это хорошо ложится на реальный B2B-софт, где право доступа часто зависит и от пользователя, и от записи, с которой он работает.

Иерархия ролей помогает, но только до определённого момента. Она подходит для общих правил вроде ROLE_SUPER_ADMIN включает ROLE_ADMIN, а ROLE_ADMIN включает ROLE_SUPPORT. Но она не решает бизнес-логику сама по себе. Если руководитель поддержки может смотреть счета только своего региона, но не менять настройки биллинга, вам всё равно нужен код в voter'ах или в доменных сервисах.

Поэтому Symfony лучше всего работает, когда вы делите задачу на две части:

• используйте роли для общих уровней доступа
• используйте voter'ы для решений на уровне записей
• храните участие в командах и владение аккаунтом в модели данных
• проверяйте делегированные действия, например приглашения пользователей или изменения биллинга, в коде

Если в приложении много комбинаций правил, стоит посмотреть на PHP-Casbin. Он хорошо подходит для продуктов с большим числом тенантов, типов ресурсов, маршрутов согласования и исключений. С ним можно моделировать правила более формально, а не писать десятки отдельных проверок. Но за это приходится платить сложностью. Небольшие команды часто начинают тормозить, если ставят policy engine раньше, чем он действительно нужен.

Обычный собственный код тоже может подойти, но только когда модель прав совсем маленькая. Простой внутренний инструмент с двумя ролями и несколькими экранами может обойтись несколькими проверками. Но как только появляются участие в командах, делегированные админские права или исключения для отдельных клиентов, такой подход быстро становится неуправляемым.

Практическое правило простое. Если вы строите решение на Symfony, начните с Security и voter'ов. Добавьте иерархию ролей для общих уровней доступа. И используйте PHP-Casbin только тогда, когда правила начинают множиться быстрее, чем команда успевает в них разбираться.

Какой пакет подходит для какой задачи

Среди пакетов PHP для аутентификации и прав доступа лучший выбор зависит от того, какая задача болит первой. В большинстве B2B-приложений один пакет не должен отвечать вообще за всё. Структура команд, доступ к отдельным записям и администрирование обычно требуют разных инструментов.

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

• Для участия в командах Jetstream хорошо подходит, если ваше приложение уже использует Laravel teams, приглашения и общие рабочие пространства. Laratrust тоже аккуратно работает с ролями в рамках команды. Spatie тоже может это делать, если включить поддержку teams и захотеть больше контроля над ролями и правами.
• Для проверок прав в PHP чаще всего лучше всего подходят Laravel policies и Symfony voter'ы. Они читаются естественно, когда доступ зависит и от пользователя, и от записи. В Laravel Bouncer тоже выглядит органично, если вы хотите проверять abilities рядом с кодом.
• Для делегирования админских прав Spatie и Laratrust часто удобнее в управлении, потому что они используют именованные наборы прав. Так проще строить админку для ролей вроде «billing admin» или «support manager».
• Для сложных крайних случаев лучше сочетать один пакет для ролей и политику в коде. Так обычные правила остаются простыми, а особые — явными.

Jetstream хорошо подходит, когда сложность в участии, а не в глубокой авторизации. Если пользователи входят в компании, переключаются между командами и приглашают коллег, он быстро даёт прочную основу. Но Jetstream не решает полностью сложные роли и права в Laravel. Скорее всего, вам всё равно понадобятся политики для правил вроде «team admin может редактировать пользователей, но не менять биллинг».

Spatie хорошо подходит, когда вам нужны понятные бизнесу роли и права. Права вроде «приглашать участников», «экспортировать отчёты» и «управлять счетами» легко объяснить. Laratrust занимает похожую нишу и часто кажется удобным, когда в центре приложения стоит именно участие в командах.

Для правил на уровне записей политики и voter'ы трудно чем-то заменить. Пакет может сказать, что пользователь — менеджер. Политика может сказать, что этот менеджер может утверждать только те счета, которые относятся к его компании. Именно здесь часто и появляются баги в правах доступа в SaaS.

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

Как выбрать за несколько шагов

Начните не с документации пакетов, а с одной страницы. Если вы не можете описать пользователей, команды и действия простыми словами, ни один пакет не спасёт вас от проблем с правами позже.

Когда вы сравниваете пакеты PHP для аутентификации и прав доступа, запишите на одной странице три вещи: кто действует, где он действует и что он может делать. Для B2B-продуктов это обычно такие роли, как владелец, менеджер, админ по биллингу, специалист поддержки и обычный участник. Ещё нужны границы команды или компании, потому что многие действия должны оставаться внутри одного клиентского аккаунта.

Хорошо работает простой процесс:

1. Составьте список всех ролей и всех действий, которые важны в ежедневной работе. Держите его простым и конкретным: пригласить участника, сменить тариф, экспортировать данные, вернуть платёж, зайти под пользователем.
2. Отметьте, какие действия остаются внутри одной компании, а какие выходят за эти границы. Большинство действий должно оставаться внутри тенанта. Доступ поддержки — это часто исключение.
3. Прогоните на бумаге несколько реальных сценариев. Может ли владелец управлять биллингом только своей компании? Может ли менеджер приглашать пользователей, но не менять платёжные данные? Может ли поддержка смотреть аккаунт, не меняя роли?
4. Начните с небольшого набора ролей. Owner, manager, billing admin и member часто достаточно для первой версии. Добавляйте особые исключения только тогда, когда видите реальную необходимость.
5. Напишите тесты прав доступа до того, как построите админские экраны. Если правила расплывчаты в тестах, в интерфейсе они будут ещё хуже.

Этот порядок важен. Команды и проверки политик обычно влияют на выбор пакета сильнее, чем названия ролей. Пакет может прекрасно выглядеть в демо, а потом развалиться, когда один пользователь принадлежит двум компаниям и у каждой из них разные права.

Небольшой пример это хорошо показывает. Допустим, финансовый руководитель работает в Company A и Company B. В A он может оплачивать счета. В B он может только смотреть их. Если пакет аккуратно поддерживает участие в командах и позволяет проверять права в контексте текущей компании, вы на более безопасной территории.

Выбирайте пакет, который упрощает обычный сценарий. Не оптимизируйте с первого дня под редкие исключения.

Простой B2B-пример

Представьте клиентский аккаунт Northstar Logistics. У него одно рабочее пространство, двенадцать сотрудников и несколько внешних помощников. Когда вы сравниваете пакеты PHP для аутентификации и прав доступа, именно такие аккаунты быстро показывают сложные места.

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

Leo — руководитель команды. Он может создавать проекты, редактировать детали проектов и переносить работу между командами. Но он не видит счета, платёжные способы и изменения подписки. Если он откроет страницу биллинга, приложение должно его заблокировать, даже несмотря на то, что он менеджер.

Nina работает в финансах. У неё роль billing admin, поэтому она может смотреть счета, обновлять платёжные способы и скачивать квитанции. Но она не должна редактировать проекты или просматривать работу команды только потому, что занимается деньгами.

Sam работает в команде поддержки у поставщика софта. Иногда ему нужен временный доступ, чтобы помочь с поломанным импортом или зависшим процессом. Такой доступ должен истекать, требовать заметки в аудите и показывать, кто его одобрил. Я бы не делал доступ поддержки обычной постоянной ролью.

У платформы есть и глобальный админ. Этот человек может управлять всем SaaS-продуктом, но по умолчанию не должен находиться внутри клиентских данных. Именно здесь многие команды расслабляются. Они дают платформенным администраторам полный доступ на чтение ко всем тенантам, а потом месяцами исправляют проблемы доверия и соответствия требованиям.

Хорошая схема делит работу на две части. Участие в команде определяет, к какому рабочему пространству относится человек. Политики определяют, что он может делать внутри этого пространства.

В Laravel роли из такого пакета, как Spatie Permission, могут обозначать людей как owner, manager или billing admin. А политики уже отвечают за реальные проверки:

• Leo может обновлять проекты в Northstar
• Nina может смотреть счета в Northstar
• Sam может заходить в Northstar только во время одобренной сессии поддержки
• Глобальный админ по умолчанию не может открывать клиентские записи Northstar

Сначала такая модель кажется немного строже. Но она же предотвращает тот тип бага в правах доступа, который появляется только после того, как ваш самый крупный клиент нанимает ещё десять сотрудников и просит журнал аудита.

Ошибки, которые приводят к багам в правах доступа

Большинство багов в правах доступа появляются ещё до первого вызова политики. Они начинаются с грязной модели доступа, слишком общих названий ролей и настроек по умолчанию, которые дают людям слишком много власти.

Одна частая ошибка — размножение ролей. Команды продолжают добавлять ещё одну роль на каждый нестандартный случай: «sales-admin-lite», «billing-manager-no-export», «support-temp». Через несколько месяцев никто уже не знает, что именно делает каждая роль. Держите роли широкими и стабильными, а для редких исключений используйте небольшой набор явных прав. Если одному клиенту нужен пользователь, который может смотреть счета, но не может возвращать платежи, это изменение права, а не новая роль.

Ещё одна проблема — прятать проверки в случайных контроллерах, задачах и helper'ах. Один endpoint проверяет isAdmin(), другой смотрит строку роли, а третий вообще ничего не проверяет. Большинство пакетов PHP для аутентификации и прав доступа умеют хорошо enforce-ить правила, но только если вы держите их в одном месте. Политики, gates или отдельный слой авторизации легче тестировать и намного труднее случайно обойти.

Scope в B2B-приложениях наносит много вреда. Глобальный админ и tenant admin — это не один и тот же человек, даже если в интерфейсе оба выглядят как «admin». Глобальные админы могут переходить границы аккаунтов. Tenant admin должен оставаться внутри одной компании или рабочего пространства. Если вы используете одно и то же имя роли для обоих случаев, рано или поздно кто-то получит доступ к данным не того клиента.

Приглашения — ещё одно слабое место. Многие команды дают приглашённому пользователю права того, кто его пригласил, или слишком щедрую роль по умолчанию, чтобы снизить трение. Это кажется удобным, пока подрядчик в первый же день не получает доступ к биллингу, управлению пользователями и правам на экспорт. Новым пользователям лучше сразу давать минимальный набор прав, а приглашающему — явно выбирать tenant и роль.

Журналы аудита особенно важны, когда что-то идёт не так. Логируйте каждое изменение роли, каждую выдачу прав и каждую сессию имперсонации. Фиксируйте, кто сделал изменение, какой аккаунт оно затронуло и когда это произошло. Если сотрудники поддержки могут входить под пользователями, логируйте ещё и начало, и конец такой сессии. Без этого следа вы не сможете объяснить инцидент или исправить процесс, который к нему привёл.

Короткая проверка перед запуском

Перед запуском тестируйте сложные случаи, а не happy path. Большинство багов в правах появляется, когда один человек совмещает две роли, у одной компании несколько команд или специалисту поддержки нужен ограниченный доступ на 15 минут.

Короткая проверка ловит очень многое:

• Проверьте, живут ли роли внутри компании или команды, а не на уровне всего приложения. Пользователь может быть администратором в одном клиентском аккаунте и обычным участником в другом. Если пакет не умеет аккуратно ограничивать область, вам придётся писать кастомные правила повсюду.
• Убедитесь, что правила на уровне записей можно выразить без хитростей. Сотрудник финансов может видеть счета только своей компании. Руководитель команды может редактировать проекты только тех команд, которыми он управляет. Если в каждом контроллере вам нужен сырой SQL, модель вам мешает.
• Проверьте делегирование с реальными ограничениями. Во многих B2B-приложениях владельцу аккаунта нужно приглашать пользователей, сбрасывать роли или управлять биллингом, не отдавая полный контроль над системой. Эти действия должны быть отдельными правами, а не одним широким переключателем «владелец может всё».
• Проверьте смену ролей простыми тестами. Повысили пользователя, убрали роль, перевели в другую команду — и сразу убедились, что изменилось. Хорошие тесты читаются почти как обычный текст и покрывают и разрешающие, и запрещающие случаи.
• Давайте сотрудникам поддержки временный доступ вместо постоянных админских прав. Имперсонация с логированием, одобрением и сроком действия безопаснее, чем выдача главной роли, которую потом никто не помнит удалить.

Один небольшой сценарий уже способен показать слабые места. Создайте две компании, в каждой — владельца, менеджера и контакт по биллингу. Затем попробуйте обычные действия: пригласить коллегу, посмотреть данные другой компании, отредактировать запись вне команды, изменить подписку и использовать доступ поддержки. Если хоть один результат кажется неожиданным, пользователи позже столкнутся с той же проблемой.

Именно здесь внимательная проверка особенно полезна. Олег часто помогает командам навести порядок в таком auth-хаосе, пока он не превратился в обращения в поддержку и рискованные обходные решения.

Что делать дальше

Не начинайте с названий пакетов. Начните с людей. Большинство B2B-приложений можно стартовать с четырёх ролей: владелец, админ, менеджер и участник. Потом запишите около десяти действий, которые люди выполняют каждую неделю, например: приглашать пользователей, утверждать счета, редактировать биллинг, экспортировать данные и управлять командой.

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

Сначала перенесите эти роли и действия в простую таблицу прав доступа, а уже потом выбирайте между пакетами PHP для аутентификации и прав доступа. Одной строки на одно действие достаточно. Добавьте столбцы для роли, области команды, того, кто может делегировать право, и того, должен ли сервис проверять владение, состояние аккаунта или ограничения по тарифу.

Небольшой черновик часто сразу показывает пробелы:

• Менеджер может утверждать сделки только для своей команды
• Админ может приглашать пользователей, но не может менять биллинг
• Владелец может назначать админов
• Сотрудник поддержки может смотреть аккаунты, но не может экспортировать данные

Сначала постройте самый маленький поток делегирования админских прав. Пусть один владелец выдаёт роль администратора. Потом этот админ приглашает участника. Затем заставьте приложение блокировать всё, что выходит за рамки этого доступа. Если этот поток неудобен уже в коде, через шесть месяцев, когда ролей станет больше, он будет ещё хуже.

Это также момент, когда стоит решить, где заканчиваются правила пакета и начинаются ваши кастомные политики. Пакеты обычно хорошо справляются с назначением ролей и базовыми проверками. Но правила на уровне записей, ограничения между командами и сложные исключения часто требуют собственного слоя политик.

Если ваше приложение сочетает роли и права в Laravel, кастомные проверки в PHP, участие в командах в SaaS и быстрые изменения продукта, короткая проверка может уберечь от болезненной переписки позже. Олег делает такую работу как Fractional CTO и может проверить модель до того, как она разрастётся по контроллерам, политикам, админским экранам и процессам поддержки.