Многие новички слышат слово authorization и путают его с authentication.
Эти два понятия тесно связаны, но решают разные задачи. Authentication отвечает на вопрос: “Кто вы?” Authorization отвечает на вопрос: “Что вам разрешено делать?”
Эту разницу легко понять на реальном примере. Представьте, что вы входите в офис компании и показываете пропуск на входе. Охрана проверяет, что пропуск действительно ваш. Это authentication. Но дальше: можете ли вы войти в финансовый отдел? Можете ли открыть серверную? Можете ли утверждать платежи? Можете ли видеть HR-данные? Эти решения уже относятся к authorization.
Authorization — это про разрешения
Самый простой способ понять authorization такой: система уже знает, кто вы, и теперь решает, к чему вам разрешён доступ и что вы можете изменять. Речь уже не об идентичности. Речь о границах полномочий.
Это важно, потому что многие системы содержат разные типы данных и действий. Не каждый пользователь должен видеть всё. Не каждый сотрудник должен получать доступ к административным инструментам. Не каждый клиент должен менять billing-настройки. Без authorization все аутентифицированные пользователи могли бы получить слишком много власти.
Простой пример
Представьте приложение для управления командой, где есть три пользователя: обычный сотрудник, менеджер и администратор. Все трое могут войти в систему с действующими аккаунтами. Значит, все трое проходят authentication. Но после входа они не должны видеть одно и то же.
- сотрудник может просматривать назначенные задачи
- менеджер может изменять рабочие процессы команды
- администратор может создавать пользователей и менять системные настройки
Приложение принимает authorization-решения каждый раз, когда определяет, кто что может видеть, менять, удалять или управлять.
Почему одного authentication недостаточно
Частая ошибка новичков — думать, что если пользователь успешно вошёл в систему, то главная проблема безопасности уже решена. Это не так. Понять, что человек — реальный пользователь, это только первый шаг. Система ещё должна решить, имеет ли этот пользователь право выполнить конкретное действие.
Например, если любой вошедший пользователь мог бы удалить все записи, увидеть приватные отчёты или изменить пароль другого человека, система всё равно была бы опасно спроектирована, даже при хорошем логине.
Authorization встречается повсюду в программных системах
Как только вы понимаете эту идею, вы начинаете замечать authorization во многих обычных продуктах:
- одни пользователи могут только читать данные, другие — редактировать
- одни участники команды могут приглашать новых пользователей, другие — нет
- одни аккаунты получают доступ к premium-функциям, другие остаются на бесплатном плане
- одни люди видят внутренние дашборды, другие — только публичные страницы
- одни API-ключи могут читать ресурсы, другие — также записывать или удалять
Все эти случаи — примеры того, как система решает не кто вы, а что вам разрешено делать.
Как системы обычно реализуют authorization
Разные системы реализуют authorization по-разному, но основная идея остаётся той же. Система может назначать роли, например user, editor, manager, admin. Она может задавать разрешения, например read, write, update, delete. Она также может применять правила на основе владельца, тарифного плана, отдела или типа ресурса.
Например, приложение для документов может позволять вам редактировать свой файл, но не чужой. Billing-система может разрешать support-команде просматривать счета, но только finance-команде — делать возвраты. Это authorization-правила в действии.
Почему в реальных системах authorization усложняется
Authorization кажется простым, пока система маленькая. Но по мере роста программы логика разрешений становится гораздо сложнее. Роли начинают пересекаться. Появляются исключения. Может понадобиться временный доступ. Одной команде нужен только read-only доступ, а другой — право редактирования только в одном разделе. Именно поэтому проектирование разрешений становится важной частью архитектуры серьёзных продуктов.
Слабая authorization-модель создаёт скрытые риски. Нечёткая модель создаёт путаницу, баги и проблемы для поддержки.
Authorization — это ещё и продуктовый дизайн
Многие думают, что authorization относится только к backend-безопасности. Но он также глубоко связан с дизайном продукта. Кто должен видеть какую кнопку? Какие пункты меню нужно скрывать? Какие действия должны быть недоступны? Какой тариф открывает какие функции? Это вопросы пользовательского опыта, построенные поверх authorization-логики.
Иными словами, authorization формирует не только безопасность, но и саму структуру продукта.
Почему это важно, даже если вы не backend-разработчик
Не нужно писать access-control-код, чтобы получать пользу от понимания authorization. Основатели, продакт-менеджеры, дизайнеры, аналитики и support-команды регулярно сталкиваются с вопросами разрешений. Когда вы хорошо понимаете authorization, многие продуктовые поведения становятся яснее: почему один пользователь видит функцию, а другой нет, почему внутренним инструментам нужны роли, и почему enterprise-продукты так много времени уделяют permissions.
Вы начинаете видеть authorization как один из ключевых способов, с помощью которых софт организует власть и доступ.
Итог
Authorization — это процесс принятия решения о том, что разрешено делать уже идентифицированному пользователю. Authentication сначала подтверждает личность. Authorization затем определяет разрешения. Когда вы понимаете эту разницу, многие программные системы становятся намного понятнее.
