“Войти через другой сервис” удобно, но что происходит внутри
Я всё чаще замечаю, что многие хорошо узнают термины OAuth 2.0, SAML, OpenID Connect, но на практике всё это для многих сливается в одну абстракцию: “ну это когда входишь через Google”
На деле различия там важные. Поэтому хочу сделать короткий разбор того, как реально работает такой вход и почему эти механизмы нельзя смешивать в одну кучу.
━━━━━━━━━━ Кто есть кто? ━━━━━━━━━━
• OAuth 2.0 это не “протокол логина”, а механизм делегирования доступа. То есть пользователь разрешает одному приложению выполнить какие-то действия или получить доступ к части данных через другой сервис ⇨Простой пример: сайт просит доступ к вашему профилю, почте, календарю или репозиториям через внешний сервис.
• OpenID Connect (OIDC) это слой идентификации поверх OAuth 2.0. Именно он отвечает на вопрос: “Кто этот пользователь?” ⇨То есть когда вы видите кнопку “Войти через Google”, очень часто под капотом речь уже не просто про OAuth 2.0, а именно про OIDC.
• SAML это тоже механизм аутентификации и передачи identity, но чаще он встречается в enterprise / corporate-среде. ⇨Особенно там, где нужен SSO между внутренними системами компании, порталом, VPN, почтой, корпоративными сервисами и т.д.
━━━━━━━━━━ Почему возникает путаница? ━━━━━━━━━━
1. Для пользователя всё выглядит одинаково: ⠀ ⠀нажал кнопку → подтвердил вход → попал в систему
2. Многие называют OAuth 2.0 вообще всей темой целиком, хотя он сам по себе не решает задачу полноценной идентификации пользователя
3. В реальной жизни интеграции часто идут комплектом: OAuth 2.0 + OIDC, и поэтому границы между ними визуально “размываются”
━━━━━━━━━━ Что происходит, когда вы жмёте “Войти через Google”? ━━━━━━━━━━
Упрощённо сценарий выглядит так: 1. Сайт отправляет вас на внешний identity provider 2. Вы проходите аутентификацию уже не на самом сайте, а у внешнего провайдера 3. Провайдер возвращает результат обратно 4. Сайт получает подтверждение, что пользователь успешно аутентифицирован, и на основании этого создаёт у себя локальную сессию
То есть сайт не всегда получает ваш пароль. Во многих сценариях он вообще его никогда не видит.
━━━━━━━━━━ Где что использовать? ━━━━━━━━━
• OAuth 2.0 — когда нужно делегировать доступ к ресурсам или API
• OpenID Connect — когда нужно не просто дать доступ, а ещё и понять, кто именно пользователь
• SAML — когда речь идёт про корпоративный SSO, федерацию identity и интеграцию между бизнес-системами
━━━━━━━━━ Итог ━━━━━━━━━
Когда вы видите кнопку “Войти через Google / GitHub / Apple / ...”,
за ней почти всегда стоит не магия, а конкретная модель доверия: ◦ кто вас аутентифицирует ◦ кто кому доверяет ◦ что именно передаётся ◦ и для чего это используется: доступ, identity или SSO
Именно поэтому OAuth 2.0, OpenID Connect и SAML лучше не смешивать в одну абстракцию “ну это просто вход через другой сервис”.
