Auth

Интеграция бэкенда с Keycloak: валидация токенов и снижение нагрузки на IdP

Интеграция бэкенда с Keycloak: валидация токенов и снижение нагрузки на IdP

Бэкенд как 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 #oauth #auth
Keycloak на практике: realms, clients, потоки, деплой

Keycloak на практике: realms, clients, потоки, деплой

От решения к практике: разворачиваем 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 #oauth #auth
Свой auth или готовый IdP: когда брать Keycloak

Свой auth или готовый IdP: когда брать Keycloak

Не «как настроить Keycloak», а решение на уровень выше: когда вообще стоит брать готовый IdP вместо своего auth. Реальная цена «сделай сам» (восемь пластов — сессии, refresh, OAuth-флоу, MFA, passkeys, федерация — каждый отдельный проект и зона риска), что закрывает Keycloak, рамка «бай vs билд» (self-hosted vs managed Auth0/Cognito), РФ-угол on-prem и честная ops-цена stateful-сервиса
#keycloak #oauth #auth