Не «какой провайдер подключить», а как устроены сами флоу: authorization code + PKCE (и почему implicit умер), client credentials для сервис-сервис, device flow для TV/CLI, token introspection (opaque) vs локальная валидация JWT по JWKS, OIDC discovery. Разница между OAuth2 (делегирование доступа) и OIDC (аутентификация поверх)
Методы входа и как они сходятся к единой сессии: беспарольный email-код и OTP с лимитами, OAuth поверх OIDC со state/PKCE, вход через Telegram (widget-HMAC и небезопасный OAuth-контраст), авто-регистрация при первом входе — и почему методы намеренно НЕ сливаются в один аккаунт по непроверенному email (fail-safe, а не готовый merge)
Заключительная статья серии — та самая ops-цена готового IdP в деталях, на отдельном production-стенде (docker-compose.prod.yml, Keycloak 26.7.0). Почему start-dev нельзя в прод и что требует production start; оптимизированный образ через kc.sh build + start –optimized; внешний PostgreSQL как единственный стейт (данные realm + таблица JDBC_PING); HA из двух реплик за nginx-LB — Infinispan-кластер с discovery через JDBC_PING (реальный лог 2-member ISPN view, mTLS JGroups) и распределённой сессией (login на реплике-1 → refresh + userinfo на реплике-2 = HTTP 200); TLS-offload против re-encrypt (реальная тонкость с alert 47); наблюдаемость — /metrics на management-порту 9000 (реальный срез: jvm heap, vendor_statistics кэшей сессий, http_server_requests), тонкость KC_HTTP_MANAGEMENT_SCHEME=http; тюнинг пула БД/кэшей/JVM; обновления мажоров (пиновка, migration notes, тест realm-экспорта, blue-green); бэкапы и DR (единственный стейт — БД + realm-as-code).
Keycloak под бренд и под внешние учётки. Часть первая — кастомная login-тема: каталог theme.properties + CSS + SVG-лого, наследование от штатной темы, тонкость с неаддитивным свойством styles, локализация через messages, подключение через volume + loginTheme; FreeMarker против keycloakify — честное сравнение. Часть вторая — identity brokering: Keycloak как брокер внешних IdP, first-broker-login и attribute mappers, запускаемая демонстрация на mock-OIDC (реальный прогон цепочки редиректов, brokered-пользователь ext-yandex-demo, federated-identity + роль user), конфиг Яндекс (тип OAuth v2 — id_token не выдаёт), честная оговорка про VK ID (PKCE + device_id — сложнее generic, вероятен адаптер) и честный разбор ЕСИА — почему её нельзя воспроизвести в учебном стенде (аккредитация Минцифры, ГОСТ-TLS).
Бэкенд как OIDC resource server: локальная JWT-валидация по JWKS + discovery против introspection на каждый запрос. Что проверяем по шагам (единственный alg, подпись по JWKS с ротацией по kid, iss, aud=backend, exp/nbf, typ=Bearer против подстановки id_token, затем realm_access.roles), Go на go-jose (coreos/go-oidc — для discovery) и Java на Spring Security oauth2ResourceServer, решение issuer-hostname через KC_HOSTNAME. Ядро — реальный замер со стенда: 40 000 запросов на /me, jwks p50 1.18 мс и 0 обращений к Keycloak против introspect p50 4.19 мс и ровно 1 обращение на запрос; когда introspection всё же нужен и как его удешевить, тюнинг lifespans, мост к authz.
От решения к практике: разворачиваем Keycloak 26.7.0 (Quarkus) в docker-compose с внешним PostgreSQL, разбираем анатомию realm (confidential vs public clients, redirect URI, realm- и client-роли, группы, client scopes), потоки authorization code + PKCE и client credentials, получаем первый access-token curl-ом к token endpoint и читаем реальный декодированный JWT (iss, aud=backend, exp, realm_access.roles). Realm-as-code через kc.sh export/import вместо click-ops, token lifespans и protocol mappers ролей.
Не «как настроить Keycloak», а решение на уровень выше: когда вообще стоит брать готовый IdP вместо своего auth. Реальная цена «сделай сам» (восемь пластов — сессии, refresh, OAuth-флоу, MFA, passkeys, федерация — каждый отдельный проект и зона риска), что закрывает Keycloak, рамка «бай vs билд» (self-hosted vs managed Auth0/Cognito), РФ-угол on-prem и честная ops-цена stateful-сервиса
