Минимальный OIDC: code flow, JWKS и дорога к PKCE

OIDC — большая спецификация. Срез, нужный для self-hosted SSO IdP, обслуживающего confidential-клиентов, существенно меньше — и мы намеренно отгружаем именно его.

Эндпоинты

• GET /.well-known/openid-configuration — Discovery.
• GET /authorize — authorization endpoint, response_type=code.
• POST /token — token endpoint, grant_type=authorization_code.
• GET /userinfo — UserInfo, Bearer access token.
• GET /jwks — JWKS для JWT, выпускаемых IdP (RS256).

Сильные дефолты, уже на месте

• Точное сравнение redirect_uri по allowlist на каждого клиента.
• Одноразовые authorization code с TTL и timing-safe сравнением.
• no-store на token endpoint — токены не оседают в посредниках.
• Только RS256 для подписи; alg никогда не берётся из запроса.

Дорога к PKCE

Сегодня флоу рассчитан на confidential-клиентов. Чтобы безопасно обслуживать публичных, нативных и SPA-клиентов, следующие шаги:

• Принимать и хранить code_challenge + code_challenge_method на /authorize.
• Проверять code_verifier на /token в constant-time сравнении.
• Анонсировать code_challenge_methods_supported в Discovery.
• Добавить at_hash в id_token, чтобы привязать его к access token.
• Валидировать iss при внутренней проверке access token.

В этом нет экзотики — это следующая страница того же минимального флоу.