Посылка, паспорт и доверенность: чем аутентификация отличается от авторизации и кто такие IdP

21 октября 2026

Эти два слова путают постоянно: в разговорах, в ТЗ и даже в документации. Звучат похоже, оба про «пустить или не пустить», только означают разное. Если их смешать, получаются дыры в безопасности и долгие споры с разработчиками.

Объясню на примере, который знаком каждому.

Почта

Вы пришли на почту за посылкой. Отстояли очередь (куда без неё) и называете оператору трек-номер или фамилию. Это идентификация: вы сказали, кто вы.

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

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

Если у вас есть доверенность от соседа, посылку отдадут. Права у вас не появились сами по себе: их вам передал владелец. Запомните этот момент, он ещё понадобится.

Если коротко:

Идентификация — «Я Иванов».
Аутентификация — «Докажи, что ты Иванов».
Авторизация — «Что Иванову можно».

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

Как это выглядит в IT

Логин в форме входа — это идентификация. Пароль, код из SMS, отпечаток пальца — аутентификация. Система проверила их и узнала пользователя.

Потом он открывает раздел «Бухгалтерия» и получает «Доступ запрещён». Тут сработала авторизация: человека узнали, но прав у него нет. Ровно как с соседской посылкой.

Забавно, что даже в HTTP с этим путаница. Код 401 Unauthorized на самом деле означает «я не знаю, кто ты» (то есть «не аутентифицирован»). А «знаю, кто ты, но нельзя» передаёт код 403 Forbidden. Так исторически сложилось, и теперь с этим живём все).

Ещё одна частая ошибка: считать, что раз человек вошёл, то ему можно всё. Многие уязвимости в веб-приложениях появляются именно так. Пользователь меняет в адресной строке id=15 на id=16 и видит чужой заказ. Это как если бы оператор, проверив паспорт, разрешил вам самому взять с полки любую коробку. Аутентификация есть, а авторизацию никто не сделал.

Откуда берутся IdP

Обратите внимание на одну деталь: почта сама не устанавливает, кто вы. Паспорт выдаёт не почта, а МВД. Почта просто доверяет документу, который выдал кто-то другой, и умеет отличить настоящий от подделки. Банк, нотариус и поликлиника доверяют тому же самому паспорту.

В IT долго было не так. Каждый сервис заводил собственную базу пользователей, то есть выдавал свой «паспорт». Почта, облако, Git, мессенджер, фотоархив, Wi-Fi в офисе. В итоге:

десять паролей у каждого сотрудника, и половина из них записана на стикере под монитором;
уволенного сотрудника нужно удалить в десяти местах, а про одиннадцатое кто-нибудь обязательно забудет;
двухфакторку приходится настраивать отдельно для каждого сервиса.

Для этого придумали IdP (Identity Provider), то есть поставщика удостоверений. Это отдельный сервис, единственная задача которого — узнавать пользователей и выдавать им «паспорт», которому доверяют остальные. Тот самый паспортный стол.

Вы с этим наверняка сталкивались: кнопки «Войти через Google», «Войти через Яндекс ID», «Войти через Госуслуги». Сайт не знает и не хранит ваш пароль, он просто доверяет тому, кто вас проверил.

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

Пользователь → приложение. Вы открываете сервис, например фотоархив.
Приложение → пользователь. Фотоархив сам вас не проверяет, а отправляет к IdP: «сходи туда, представься». Технически это обычный редирект в браузере.
Пользователь → IdP. Вы вводите пароль и второй фактор. Важно: их видит только IdP, приложение их не видит никогда.
IdP → пользователь. IdP выдаёт подписанный «документ» (токен), где написано, кто вы и в каких группах состоите.
Пользователь → приложение (жёлтая стрелка вверх). Браузер передаёт этот документ фотоархиву. Тот проверяет подпись, как оператор на почте проверяет защиту на бланке паспорта, и пускает вас. А что именно вам разрешено, решает уже он сам.

Если завтра вы откроете Nextcloud, шаг 3 пропустится. У IdP уже есть ваша сессия, поэтому он сразу выдаст новый токен. Это и есть SSO (Single Sign-On), единый вход: вы один раз вошли утром и дальше ходите по всем сервисам без новых паролей. Это главная радость пользователя и одно из главных удобств для админа.

Получается, что IdP отвечает за аутентификацию (шаги 3–4), а авторизация происходит на шаге 5 и чаще всего остаётся за самим приложением. Хотя группы и роли обычно хранятся как раз в IdP.

Для придирчивых: в SAML документ действительно несёт браузер. В OpenID Connect браузер на шаге 5 приносит только одноразовый код, а сам токен приложение забирает у IdP напрямую, «служебным ходом». Так безопаснее: токен не светится в браузере. Но общая идея та же.

Немного терминов

Когда начнёте настраивать IdP, документация сразу закидает вас словами. Вот основные:

SP (Service Provider) или RP (Relying Party), «проверяющая сторона». Это само приложение, которое доверяет IdP. В нашем примере это почтовое отделение.
Утверждения (claims). Строчки внутри документа: «email = ivanov@company.ru», «группа = Бухгалтерия». Как графы в паспорте. По ним приложение и решает, что вам можно.
Токен. Сам документ. В SAML это XML, в OIDC — JWT, строка из трёх частей через точку. Если вставить JWT на jwt.io, видно все утверждения открытым текстом. Поэтому секреты в токен класть нельзя: он подписан, но не зашифрован. Паспорт ведь тоже может прочитать любой, кто его открыл.
Метаданные. Файл или URL, по которому IdP и приложение узнают друг о друге: адреса, сертификаты, поддерживаемые протоколы. Обменялись метаданными — значит, наполовину настроили.
SP-initiated и IdP-initiated вход. В первом случае вы открываете приложение и оно отправляет вас к IdP (как на схеме выше). Во втором заходите на портал IdP и уже оттуда кликаете по приложению. Первый вариант правильнее и безопаснее.
Провижининг (SCIM, JIT). IdP только проверяет, кто вы. А чтобы учётка появилась в приложении (и, что важнее, исчезла при увольнении), нужен отдельный механизм. JIT создаёт пользователя при первом входе, SCIM синхронизирует учётки заранее.

Немного аббревиатур

Ещё о протоколах. С IdP почти всегда приходится иметь дело именно с ними:

SAML 2.0. Старый и надёжный, на XML. Его любят корпоративные системы.
OAuth 2.0. Важно: это протокол авторизации, а не входа. Помните доверенность на соседскую посылку? OAuth — это она и есть. Вы разрешаете приложению, например, читать ваш календарь и не отдаёте ему свой пароль. Он отвечает на вопрос «что этому приложению можно от моего имени», а не «кто я».
OpenID Connect (OIDC). Надстройка над OAuth 2.0, которая добавляет аутентификацию. К доверенности прикладывают ещё и паспорт. Сейчас это фактический стандарт для «Войти через…».
LDAP / Kerberos. Классика корпоративных сетей, тот самый Active Directory.

Путаница между OAuth и OIDC — это та же путаница между авторизацией и аутентификацией, только на уровне протоколов)

Какие бывают IdP

Сначала важная оговорка: каталог и IdP — не одно и то же. Active Directory, FreeIPA, OpenLDAP, ALD Pro, Samba AD — это картотеки, где хранятся пользователи, пароли и группы. Они хорошо работают внутри локальной сети по Kerberos и LDAP, но веб-приложение из интернета по Kerberos не пойдёт. IdP стоит поверх каталога и переводит его на язык веба: SAML и OIDC. Если продолжить аналогию: каталог — это архив паспортного стола, а IdP — окошко, где выдают документы.

Дальше IdP удобно разделить на несколько групп.

Корпоративные, на своих серверах

Keycloak. Open source от Red Hat. Пожалуй, самый популярный self-hosted IdP в мире. Умеет SAML и OIDC, подключается к AD/LDAP как к источнику пользователей и может сам выступать посредником перед Google, ЕСИА или другим IdP (identity brokering). Для разных компаний или проектов в нём создаются отдельные «области» (realms). Из минусов: Java, требователен к памяти, и разбираться в нём придётся вдумчиво.

Отечественные корпоративные

С импортозамещением этот класс быстро вырос. Самые заметные: Avanpost FAM, Blitz Identity Provider и Indeed Access Manager. По возможностям это аналоги Keycloak: SSO, MFA, SAML/OIDC, интеграция с AD и отечественными каталогами. Плюс есть то, что важно для госсектора и крупных компаний: реестр российского ПО, сертификаты, поддержка ЕСИА и отечественной криптографии.

Облачные (IDaaS)

Microsoft Entra ID (бывший Azure AD), Okta, Google Workspace, Яндекс 360 для бизнеса. Серверы не нужны: подписка, настройка в браузере, и готово. Платите деньгами и тем, что база пользователей живёт у чужого дяди.

Self-hosted для дома и небольших команд

Authentik. Современный, с приятным интерфейсом. Умеет и OIDC/SAML, и работу в режиме прокси перед приложениями, которые никакого SSO не знают.
Authelia. Лёгкий, ставится перед reverse proxy (nginx, Traefik, Caddy) и добавляет двухфакторку к сервисам, которые сами её не умеют.
Zitadel, Kanidm. Помоложе, но тоже интересные.

Например, Immich, о котором я писал недавно, умеет вход через OIDC. Поднимаете Authentik, подключаете к нему Immich, Nextcloud, Gitea и прочее, и у всей семьи один логин на всё домашнее хозяйство.

Публичные

Google, Яндекс ID, VK ID, Сбер ID, T-ID и, конечно, ЕСИА. Это IdP для обычных людей: каждый сайт, на котором есть кнопка «Войти через…», полагается на один из них. Госуслуги здесь ближе всего к настоящему паспортному столу.

Как выбрать

Есть AD, нужна гибкость и open source → Keycloak поверх AD.
Госсектор или требования к реестру ПО → отечественные решения.
Офиса и серверов нет, всё в облаке → IDaaS.
Дом, хоумлаб, небольшая команда → Authentik или Authelia.

Что важно помнить

IdP — это единая точка входа, а значит и единая точка отказа. Если упал IdP, никто никуда не войдёт. Резервирование и бэкапы обязательны.
Взломали IdP — получили доступ ко всему. Это как украсть бланки паспортов вместе с печатью. Поэтому двухфакторка на нём обязательна, а лучше аппаратные ключи или passkeys. Ключи подписи токенов храните как зеницу ока.
Аутентификация не отменяет авторизацию. Даже если IdP сказал «это Петров», приложение всё равно должно проверить, можно ли Петрову туда, куда он пытается попасть. Паспорт — ещё не повод выдавать чужие посылки.
Отключение учётки в IdP не всегда мгновенно отзывает доступ: уже выданные токены живут до истечения срока. Это как доверенность, которую отозвали, а на почте об этом ещё не знают. Делайте срок жизни токенов коротким.
Выдавайте минимальные права. Доверенность «на получение всех отправлений на любое имя» не нужна никому)

Если интересно, в следующих постах могу показать на практике, как поднять Authentik или Keycloak и подключить к нему пару сервисов. Пишите в комментариях в Max или в Telegram.