1. Надо закрыть endpoint
Когда команда говорит «этот endpoint надо закрыть», она почти всегда на самом деле имеет в виду две разные задачи.
Первая задача: понять, кто делает запрос. Это вопрос идентичности caller’а. Система должна отличить анонимного клиента от известного пользователя, а одного пользователя — от другого. Именно эту работу делает authentication.
Вторая задача: понять, что этому caller’у разрешено. Даже если система уже знает, кто пришёл, это ещё не означает, что действие допустимо. Обычный пользователь может успешно войти в систему и при этом не иметь права публиковать контент или менять роли другим пользователям. Эту работу делает authorization.
Очень важно почувствовать, что это не два названия для одной и той же проверки. Это два разных решения. Публичное чтение опубликованной статьи — хороший пример, где authorization говорит «разрешено», хотя authentication вообще не обязана происходить. А попытка обычного пользователя вызвать editor-операцию — хороший пример, где authentication уже успешна, а authorization всё равно говорит «нет».
2. Authentication: кто же делает запрос
Authentication отвечает на вопрос «кто передо мной?». В классическом сценарии это происходит через логин и пароль, но на уровне идеи важнее другое: система должна получить доверяемый способ связать запрос с конкретным caller’ом.
record LoginRequest(String username, String password) {}В такой модели password — это не «данные профиля». Это то, чем caller подтверждает свою личность. То есть здесь уже появляется важное слово: credentials. Credentials — это данные подтверждения. В username/password-сценарии это пароль. Позже в курсе вы увидите другие формы подтверждения, но сейчас достаточно удержать сам принцип.
После успешного подтверждения системе уже не обязательно таскать весь доменный профиль пользователя за собой. Для решений по безопасности ей обычно нужен более компактный объект — principal. Principal — это security-представление caller’а, а не вся биография пользователя из БД. Иногда это username, иногда id, иногда комбинация нескольких полей. Смысл в том, что security-слою не нужна лишняя доменная тяжесть.
Очень полезно почувствовать разницу между двумя фразами. «У нас есть пользователь в БД» — это ещё не authentication. «Система считает текущий запрос запросом от конкретного caller’а» — вот это уже ближе к делу. Без этой связки весь разговор о доступе повисает в воздухе.
3. Authorization: пользователю можно не всё 🚦
Как только caller стал известен системе, начинается следующий вопрос: «и что теперь ему разрешено?». Здесь живёт authorization.
Представьте обычные сценарии нашего проекта. GET /api/public/articles может быть разрешён без подтверждённого пользователя. GET /api/me уже требует известного caller’а. POST /api/editor/drafts/{id}/publish требует не только известного caller’а, но и определённого набора прав. А GET /api/drafts/{id} поднимает ещё один уровень сложности: мало знать, кто это; нужно понять, имеет ли он отношение к конкретному объекту.
Именно здесь полезно привыкнуть к простой мысли: пользователь может быть аутентифицирован и при этом не авторизован. Это не «сломанная система», а наоборот, признак того, что система умеет различать состояния. Она знает, кто пришёл, и при этом всё ещё может сказать: «этот человек не должен делать данное действие».
Это так же работает и наоборот: действие может быть авторизовано без аутентификации. Публичная статья — это разрешённый сценарий для анонимного клиента. То есть authentication и authorization не только разные по смыслу, но и не обязаны всегда идти пакетом «либо оба есть, либо обоих нет».
4. Principal, credentials, role и authority: как не смешать 🧩
Теперь можно собрать базовый словарь в одну компактную картину. Термины ниже нужны не для экзамена по глоссарию, а чтобы одинаково обсуждать систему в коде, конфигурации и команде.
| Термин | Простой смысл | Что легко перепутать |
|---|---|---|
| principal | кто сейчас считается caller’ом с точки зрения security | полную доменную сущность пользователя |
| credentials | чем caller подтверждает свою личность | данные профиля |
| role | крупная категория доступа | точное право на действие |
| authority | более точное право на действие | роль целиком |
Role в нашем проекте — это, например, USER, EDITOR, ADMIN. Это удобный грубый слой разделения доступа. Authority — это уже более точное право, вроде draft:publish или user:manage. Не каждый курс обязан глубоко уходить в детальную модель прав, но различать крупные роли и точные права полезно с самого начала.
Отдельно важно не подменять ownership ролью. Правило «это мой черновик» не живёт внутри USER как такового. Все обычные пользователи могут иметь одну и ту же роль, но разные черновики. Поэтому owner-only — это не разновидность роли, а отдельный тип проверки, завязанный на отношении между caller’ом и конкретным объектом.
5. Session, token и SecurityContext — пока на уровне идеи
На первом уровне вам ещё не нужны детали про фильтры и внутреннюю механику, но три слова полезно ввести уже сейчас, чтобы позже не было ощущения «откуда это вообще взялось».
Session — это stateful-модель, в которой сервер помнит, что запросы от этого клиента относятся к одному и тому же уже подтверждённому пользователю. Token — другой способ связать запрос с caller’ом: клиент приносит с собой специальный артефакт доступа, а сервер по нему восстанавливает identity и права. Это разные модели, и курс специально покажет обе, но не смешает их в кашу.
Важно ещё одно тонкое различие: пароль и bearer token не стоит называть полными синонимами. В классическом login-flow пароль — это credentials. В stateless-модели token становится отдельным артефактом доступа, с которым связаны свои правила жизни и свои риски. Если смешать эти слова заранее, разговор о stateful и stateless моделях потом начнёт путаться.
SecurityContext на уровне идеи — это место, где приложение держит текущую security-картину запроса. Кто сейчас caller? Считается ли он аутентифицированным? Какие у него права? Пока достаточно именно этой общей мысли. Позже вы увидите, как эта картина собирается технически. Сегодня важно лишь понять, что у системы вообще должно быть «место правды» про текущего caller’а.
6. Без словаря Spring Security кажется магией 🪄
Если слова смешаны, фреймворк всегда выглядит страшнее, чем он есть. Тогда SecurityContext кажется загадочным контейнером «чего-то про пользователя», roles и authorities начинают плавать, token и credentials звучат как взаимозаменяемые слова, а authentication и authorization превращаются в один размытый термин «ну типа безопасность».
Но как только словарь встаёт на место, многое упрощается 💡 Позже вы встретите SecurityContext, AuthenticationManager, SecurityFilterChain, request-level rules и method-level rules. И они уже не будут висеть в воздухе. Вы сможете читать их через обычные человеческие вопросы: кто делает запрос, чем это подтверждено, где хранится текущая security-картина и что этому caller’у разрешено.
Вот почему словарь нельзя воспринимать как сухой «теоретический остров». Он нужен не сам по себе, а чтобы следующая механика читалась как инженерная логика, а не как магия. Если язык не собран, любая security-конфигурация превращается в копирование заклинаний. Если язык собран, конфигурация начинает быть объяснимой.
7. Типичные ошибки 🙀
Ошибка №1: использовать authentication и authorization как одно и то же слово.
Это самая базовая путаница, а из неё потом растут почти все остальные. Сначала система должна понять, кто caller. И только потом — что ему можно. Иногда первое уже есть, а второе всё ещё нет. Иногда второе тривиально разрешает действие даже без первого.
Ошибка №2: считать principal полной доменной сущностью пользователя.
Когда в security-слой начинают тащить весь профиль, лишние поля и бизнес-данные, система становится тяжелее и менее прозрачной. Security-слою обычно нужен компактный ответ на вопрос «кто это?», а не вся история пользователя.
Ошибка №3: путать роль и ownership.
Роль USER не знает, чей именно это черновик. Если вы пытаетесь решить задачу «свой/чужой» только через роли, почти наверняка откроете лишний доступ или, наоборот, запретите нужный сценарий.
Ошибка №4: называть session и token одинаковыми механизмами.
Оба помогают связать запрос с caller’ом, но делают это принципиально разными способами. Если рано сгладить это различие, позже будет трудно понять, почему у stateful и stateless моделей настолько разные компромиссы.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ