OAuth2, OIDC

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

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

Роли в OAuth2:

  • Resource Owner — пользователь (владелец данных)
  • Client — ваше приложение, которое хочет доступ
  • Authorization Server — Google, Keycloak и т.п. (выдаёт токены)
  • Resource Server — API, к которому нужен доступ

Упрощённый Authorization Code Flow:

1. Пользователь нажимает "Войти через Google"
2. Редирект на accounts.google.com/?client_id=...&redirect_uri=...
3. Пользователь логинится на Google и даёт согласие
4. Google редиректит обратно: /callback?code=AUTH_CODE
5. Приложение обменивает code → access_token (server-side, безопасно)
6. Приложение использует access_token для запросов к API

OIDC (OpenID Connect) — слой поверх OAuth2, добавляющий аутентификацию: кроме access_token выдаётся id_token с данными о пользователе (email, имя). OAuth2 — про авторизацию (доступ к ресурсам), OIDC — про аутентификацию (кто ты).

Копнуть глубже

Scopes — что именно разрешает токен. При запросе токена приложение указывает нужные scope: openid email profile — это OIDC-скоупы, read:repositories — GitHub-специфичные. Пользователь видит на странице согласия, что именно он разрешает. Токен не имеет доступа к тому, что не было в scope.

access_token vs id_token vs refresh_token:

  • access_token — предъявляется Resource Server для доступа к API (короткоживущий, минуты/часы)
  • id_token — JWT с данными о пользователе для самого приложения, не для API (OIDC)
  • refresh_token — долгоживущий, используется только для получения нового access_token (не отправляется в API-запросах)

Keycloak — open-source Authorization Server для своей инфраструктуры: можно запустить у себя и получить полноценный сервер авторизации с ролями, федерацией через Google/GitHub (social login) и LDAP/AD интеграцией.

В Spring Security интеграция через spring-boot-starter-oauth2-client и spring-boot-starter-oauth2-resource-server:

// приложение как Resource Server — проверяет JWT-токены
@EnableWebSecurity
http.oauth2ResourceServer(oauth2 -> oauth2.jwt(Customizer.withDefaults()));

Spring сам скачивает JWKS (публичные ключи) с Authorization Server и проверяет подписи токенов.

🎤 Закрыл тему, если можешь объяснить:
• зачем OAuth2 и почему пароль пользователя не нужен стороннему приложению;
• разницу OAuth2 и OIDC, что такое scope (если дошёл до 2-го слоя).