Auth

Passkeys и WebAuthn на вебе: passwordless без фишинга

Passkeys и WebAuthn на вебе: passwordless без фишинга

Как убрать пароль на вебе: WebAuthn/FIDO2 — асимметричная криптография вместо секрета, сервер хранит только публичный ключ, а подпись привязана к origin — поэтому фишинг и утечка БД перестают давать вход. Registration (attestation) и login (assertion), resident keys и синхронизируемые passkeys, привязка к origin, UX и фолбэки — и что нужно на бэкенде, чтобы это принять

MFA и TOTP: второй фактор, recovery-коды и step-up

MFA и TOTP: второй фактор, recovery-коды и step-up

Пароль или OAuth — один фактор; второй закрывает кражу учётки. Как устроен TOTP (RFC 6238: общий секрет + время → код), почему он лучше SMS, как хранить секрет и восстанавливать доступ (recovery-коды), что такое step-up authentication (запросить фактор только на опасное действие) и куда движется мир после паролей — мостик к passkeys

OAuth2 и OIDC вглубь: authorization code, PKCE, device flow

OAuth2 и OIDC вглубь: authorization code, PKCE, device flow

Не «какой провайдер подключить», а как устроены сами флоу: authorization code + PKCE (и почему implicit умер), client credentials для сервис-сервис, device flow для TV/CLI, token introspection (opaque) vs локальная валидация JWT по JWKS, OIDC discovery. Разница между OAuth2 (делегирование доступа) и OIDC (аутентификация поверх)

Refresh на клиенте: несколько устройств и вкладок

Refresh на клиенте: несколько устройств и вкладок

Самая болезненная часть авторизации — обновление токенов на клиенте: независимые сессии на устройствах, гонка refresh нескольких вкладок с общей cookie (перезапись токена, ложный разлогин, фантомные сессии) и её решение — grace-period и refresh-lock на сервере плюс BroadcastChannel и Web Locks на клиенте

Вход и регистрация: email-код, OAuth, OTP, Telegram

Вход и регистрация: email-код, OAuth, OTP, Telegram

Методы входа и как они сходятся к единой сессии: беспарольный email-код и OTP с лимитами, OAuth поверх OIDC со state/PKCE, вход через Telegram (widget-HMAC и небезопасный OAuth-контраст), авто-регистрация при первом входе — и почему методы намеренно НЕ сливаются в один аккаунт по непроверенному email (fail-safe, а не готовый merge)

Сложный путь: выделенный auth, JWT и refresh в Redis

Сложный путь: выделенный auth, JWT и refresh в Redis

Авторизация для многих микросервисов без общей БД сессий в горячем пути: выделенный auth-сервис выпускает JWT access + opaque refresh, сервисы валидируют JWT локально общим middleware, refresh-сессии в Redis, роли в claims, глобальный logout — и честная цена stateless: отзыв только через короткий TTL access и ревокацию refresh

Модели сессий: opaque vs JWT, один сервис против многих

Модели сессий: opaque vs JWT, один сервис против многих

С чего начинается авторизация: серверные opaque-сессии против stateless JWT, stateful vs stateless, отзыв и ревокация, access и refresh, где хранить токены на клиенте — и когда достаточно сессии в Redis, а когда нужен выделенный auth

Keycloak в production: HA, БД, бэкапы, обновления

Keycloak в production: HA, БД, бэкапы, обновления

Заключительная статья серии — та самая 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 под свой продукт: экраны логина и внешние провайдеры

Keycloak под свой продукт: экраны логина и внешние провайдеры

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).