Аутентификация и авторизация

Аутентификация: сессии, токены и “что считать логином”

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

Когда вы говорите “добавить логин”, вы на самом деле выбираете три вещи:

1. Механизм: сессия (cookie) или токен (API).
2. Провайдера личности: локальная база пользователей или внешний SSO/OAuth.
3. Сценарии безопасности: 2FA, ограничения по устройствам, rate limiting, восстановление пароля, подтверждение email.

Laravel: Breeze, Jetstream, Fortify — что выбрать и зачем

В Laravel аутентификация — это “собранный путь”: вы берёте пакет‑скелет и дальше наращиваете функциональность.

Breeze: быстрый старт “без магии”

Laravel Breeze — это лёгкий scaffolding:

• страницы логина/регистрации,
• восстановление пароля,
• подтверждение email (если включите),
• и стандартные контроллеры/маршруты.

Плюс Breeze в том, что он обычно остаётся понятным для Junior’а: минимум “платформенной магии”, максимум читабельных файлов.

Jetstream: “комбайн” для продуктовых кейсов

Jetstream берут, когда нужно больше “из коробки”:

• профили,
• 2FA,
• (опционально) команды/тенанты,
• готовый UI‑слой под выбранный стек.

Минус — выше порог входа: больше кода, больше концепций.

Fortify: когда UI ваш, а логика — стандартная

Fortify — это “headless” слой аутентификации: маршруты/экшены/правила, но без готовых страниц (логин, регистрация и т.п.).

Он удобен, когда вы хотите:

• оставить стандартную механику (логин/логаут, reset password, email verification, 2FA),
• но сверстать и построить UX сами (свои формы, свои страницы, свой фронтенд: Blade/Inertia/SPA).

Важно не путать: Fortify не заменяет токены для API. Если вам нужны API‑токены/доступы — это обычно Sanctum/Passport, а Fortify — про “как логиниться” и “как живёт сессия/учётка”.

Laravel: сессии как дефолт (и почему это хорошо)

Middleware auth как базовая граница

Самая важная привычка в Laravel: доступ к “личным” страницам закрывается на уровне маршрутов:

        use Illuminate\Support\Facades\Route;

Route::middleware(['auth'])->group(function () {
    Route::get('/dashboard', fn () => view('dashboard'));
});

    

Так вы не размазываете if (!Auth::check()) по контроллерам и шаблонам.

Логин “вручную” (чтобы понимать, как это работает)

Даже если вы используете Breeze, полезно один раз увидеть базовую механику:

        use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth;

public function login(Request $request)
{
    $credentials = $request->validate([
        'email' => ['required', 'email'],
        'password' => ['required'],
    ]);

    if (Auth::attempt($credentials, remember: true)) {
        $request->session()->regenerate();
        return redirect()->intended('/dashboard');
    }

    return back()->withErrors([
        'email' => 'Неверный email или пароль.',
    ])->onlyInput('email');
}

    

Три ключевых детали:

• Auth::attempt() — проверка пары email/password и вход в сессию.
• session()->regenerate() — защита от фиксации сессии.
• intended() — возвращает пользователя туда, куда он хотел попасть до логина.

Laravel: токены для API (Sanctum/Passport) — не путайте с “логином на сайте”

Если у вас есть API, чаще всего вы выбираете один из двух путей:

• Sanctum — хороший дефолт для “токенов для пользователей” и SPA (простая модель personal access tokens + cookie‑режим для SPA).
• Passport — OAuth2‑сервер внутри Laravel (сильнее, но тяжелее).

Минимальный пример “персонального токена” (идея):

        use Illuminate\Http\Request;

public function token(Request $request): array
{
    $user = $request->user();
    $token = $user->createToken('api')->plainTextToken;

    return ['token' => $token];
}

    

Laravel: OAuth и социальный логин (Socialite)

В Laravel “соцлогин” чаще всего реализуют через Socialite:

• редирект на провайдера,
• callback,
• создание/связывание пользователя.

Схема (упрощённо):

        use Laravel\Socialite\Facades\Socialite;

public function redirectToGoogle()
{
    return Socialite::driver('google')->redirect();
}

public function handleGoogleCallback()
{
    $socialUser = Socialite::driver('google')->user();

    // Здесь: найти/создать пользователя по provider_id/email и залогинить.
}

    

Bitrix: пользователи и аутентификация (классика через CUser и “по‑D7” через Engine)

В Битриксе аутентификация — это не “подключаем пакет”, а функция платформы:

• пользователи хранятся в таблицах ядра,
• права и группы — тоже часть ядра,
• формы логина/регистрации часто подключаются как готовые компоненты/страницы,
• и многое “ожидается” системой (сессия, sessid, механика авторизации).

Вариант A (классика): $USER/CUser — то, что вы чаще увидите в проектах

Базовые проверки: авторизован ли пользователь

Самая распространённая проверка в сайтах Битрикса:

        global $USER;

if (!$USER->IsAuthorized()) {
    LocalRedirect('/auth/');
}

    

CSRF‑барьер в форме: sessid

Если вы обрабатываете POST на сайте, у вас почти всегда есть пара:

• в форме: bitrix_sessid_post()
• в обработке: check_bitrix_sessid()

Это тот же смысловой слой, что @csrf в Laravel.

Вход/выход: как понимать “сессию в Битриксе”

В классическом сценарии Битрикс использует сессионную модель: пользователь “вошёл” — дальше вы проверяете доступ через $USER и права.

Вариант B (D7‑подход): CurrentUser, UserTable, D7‑контроллеры и action filters

Если вы “топите за D7”, удобно отталкиваться от двух вещей:

• текущий пользователь как объект: \Bitrix\Main\Engine\CurrentUser::get(),
• обработчики как контроллеры: \Bitrix\Main\Engine\Controller + ActionFilter\* (практический аналог middleware).

Текущий пользователь без global $USER

        use Bitrix\Main\Engine\CurrentUser;

$currentUser = CurrentUser::get();
$userId = (int)$currentUser->getId();

if ($userId <= 0) {
    LocalRedirect('/auth/');
}

    

Тут нет отдельного isAuthorized(): самый простой критерий — есть ли ID.

Получить данные пользователя “по‑D7” (ORM)

        use Bitrix\Main\UserTable;

$user = UserTable::getById($userId)->fetch();

// $user['LOGIN'], $user['EMAIL'], $user['NAME'], ...

    

Защитить endpoint/экшен через action filters (D7‑контроллер)

Пример контроллера, где доступ к действию требует аутентификации и правильного HTTP‑метода:

        <?php

use Bitrix\Main\Engine\ActionFilter;
use Bitrix\Main\Engine\Controller;
use Bitrix\Main\UserTable;

final class ProfileController extends Controller
{
    public function configureActions(): array
    {
        return [
            'me' => [
                'prefilters' => [
                    new ActionFilter\Authentication(),
                    new ActionFilter\HttpMethod([ActionFilter\HttpMethod::METHOD_GET]),
                ],
            ],
        ];
    }

    public function meAction(): array
    {
        $userId = (int)$this->getCurrentUser()->getId();
        $user = UserTable::getById($userId)->fetch();

        return [
            'id' => $userId,
            'login' => $user['LOGIN'] ?? null,
            'email' => $user['EMAIL'] ?? null,
        ];
    }
}

    

Смысл: проверка “вошёл или нет” делается до выполнения action — ровно как в Laravel через middleware.

Bitrix: токены/интеграции и OAuth (реальность проектов)

У Битрикса сильная сторона — экосистема интеграций:

• есть штатный REST‑слой для интеграций,
• часто есть OAuth‑сценарии (особенно когда речь про приложения/внешние системы),
• и “права приложения” живут отдельно от “прав пользователя на сайте”.

Рекомендация “по‑взрослому”: не пытаться прикрутить один универсальный токен для всего.

Типовое разделение:

• сайт/личный кабинет — через сессии и обычного пользователя,
• внешние интеграции — через REST/OAuth‑механику и отдельные ключи/клиенты,
• внутренний сервис‑к‑сервису — через сервисные учётки и ограниченные права (если это допустимо).

Авторизация: политики, роли, права и “как не размазать проверки”

Авторизация ломается одинаково в обоих стеках, если проверка прав:

• разбросана по 30 контроллерам,
• частично живёт в шаблонах,
• и не имеет единого “языка” (кто может что делать).

Нормальная цель: вы хотите, чтобы разработчик мог ответить на вопрос:

“Где у нас решается, можно ли пользователю редактировать пост?”

И ответ был: “Вот policy / вот сервис / вот одна точка”.

Laravel: Gates и Policies — читабельный стандарт на проверку прав

Policy как “правила доступа к сущности”

Политика в Laravel — это по сути набор методов:

• view, create, update, delete,
• и любые кастомные действия, которые важны для домена.

Пример идеи (упрощённо):

        namespace App\Policies;

use App\Models\Post;
use App\Models\User;

final class PostPolicy
{
    public function update(User $user, Post $post): bool
    {
        return $user->id === $post->author_id || $user->is_admin;
    }
}

    

Дальше вы можете использовать это:

• в контроллере через authorize() / Gate::allows(),
• в Blade через @can('update', $post),
• и в роутинге через middleware (в зависимости от подхода проекта).

Laravel: авторизация как часть контроллера (без “сюрпризов”)

Контроллер, который обновляет пост, обычно выглядит так:

        public function update(UpdatePostRequest $request, Post $post)
{
    $this->authorize('update', $post);

    $post->update($request->validated());

    return redirect()->route('posts.show', $post);
}

    

Bitrix: группы, роли и права доступа (и почему важно договориться о модели)

В Битриксе “права” исторически живут в нескольких плоскостях:

• группы пользователей (как базовый RBAC‑слой),
• права на модули/функции (кто может что делать в рамках модуля),
• права на контент/сущности (например, на разделы/элементы/файлы — зависит от конкретной подсистемы).

Самая частая практика: группы как роли

В реальных проектах часто делают:

• “Администраторы”,
• “Менеджеры”,
• “Контент‑редакторы”,
• “Клиенты”,

и проверяют принадлежность к группе.

Упрощённый пример:

        global $USER;

if (!$USER->IsAuthorized()) {
    LocalRedirect('/auth/');
}

$groups = $USER->GetUserGroupArray();
$isManager = in_array(7, $groups, true); // 7 — условный ID группы “Менеджеры”

if (!$isManager && !$USER->IsAdmin()) {
    ShowError('Недостаточно прав.');
    return;
}

    

Это работает, но важно помнить слабое место: “группа как роль” быстро разрастается, если нет правил.

То же самое “по D7”: CurrentUser и проверка групп/операций

Если вы используете D7‑контроллеры или просто хотите унифицировать стиль, удобно брать группы из CurrentUser:

        use Bitrix\Main\Engine\CurrentUser;

$currentUser = CurrentUser::get();
$userId = (int)$currentUser->getId();

if ($userId <= 0) {
    LocalRedirect('/auth/');
}

$groups = $currentUser->getUserGroups(); // массив ID групп
$isManager = in_array(7, $groups, true);

if (!$isManager && !$currentUser->isAdmin()) {
    ShowError('Недостаточно прав.');
    return;
}

    

Ещё один полезный D7‑инструмент — проверка “операций”:

        use Bitrix\Main\Engine\CurrentUser;

if (!CurrentUser::get()->canDoOperation('my_module_edit_post')) {
    ShowError('Недостаточно прав.');
    return;
}

    

Практический совет: одна точка проверки прав

Даже если вы используете группы, старайтесь, чтобы проверки прав были:

• в одном сервисе/классе,
• или хотя бы в одном наборе функций,

а не в каждом компоненте/странице.

Например, концептуально:

• Access::canEditPost($userId, $postId)
• Access::canManageCatalog($userId)

Смысл тот же, что у policies в Laravel: правила становятся читаемыми и переиспользуемыми.

Bitrix: проверка прав “в коде” — что важно не забывать

Кейс А Не путать “вошёл” и “может”

$USER->IsAuthorized() отвечает только на вопрос “есть ли личность”.
Право на действие нужно проверять отдельно (группа/операция/контекст).

Кейс B Не делать проверки в template.php

Шаблон должен рендерить, а не решать “можно/нельзя”.
Если вы скрыли кнопку “удалить” в шаблоне, но не проверили право на удаление в обработчике — это не безопасность, это косметика.

Кейс C Дублирование правил = будущая ошибка

Если “право менеджера” проверяется в 10 местах, в 11‑м вы забудете.
Лечится только архитектурно: один слой доступа и единые функции/сервисы.

Сессии vs токены: короткая шпаргалка

Сессия (cookie)

• удобно для браузера,
• проще защищать CSRF,
• проще “выйти на всех устройствах” (если есть серверное хранение/инвалидация),
• обычно меньше ошибок у команды.

Токен (API)

• удобен для внешних клиентов и интеграций,
• требует дисциплины по хранению (особенно в браузере),
• требует понятной модели ротации/отзыва,
• и почти всегда требует отдельной модели прав (scopes/abilities).

Сравнительная таблица: аутентификация и авторизация

Шкала (как и раньше): от -2 до +2.