3.1 KiB
3.1 KiB
Промпт для Claude Opus 4 — архитектура OIDC/JWT для внешнего auth-api
Контекст (не анализируй)
Делаем микросервис на Node.js + Express. Он стоит ЗА общим auth-api платформы. Платформа сама не наша, мы не можем менять Keycloak.
Схема авторизации платформы:
- Браузер → lk-api-gateway → Keycloak (логин)
- После логина платформа обменивает code на токен через СВОЙ auth-api
- auth-api выпускает JWT с
"iss": "auth-api"(не Keycloak!) - Фронтенд платформы хранит access_token в localStorage и шлёт
Authorization: Bearer <token>к своему бэкенду
Нам неизвестно:
- JWKS URL auth-api (публичный ключ для проверки подписи)
- Как именно фронтенд платформы будет вызывать НАШ сервис (прямой запрос браузера с токеном? Или через их API-гейтвей?)
- Есть ли у нас доступ к этому auth-api или только к самому JWT
Реальный JWT (из HAR трафика):
{
"iss": "auth-api",
"sub": "0199e325-1cdf-7cda-9319-e5302a85e291",
"ClientID": "WZ01325",
"company_id": "3e64aac6-dcfc-4082-88dc-da19c86555a5",
"company_name": "Тест",
"email": "tazet@narod.ru",
"token_type": "access",
"realm_access": { "roles": null },
"resource_access": { "account": { "roles": null } },
"groups": null
}
Что нужно
Предложи стратегию проверки токенов в нашем сервисе. Мы не знаем JWKS URL auth-api и не имеем к нему доступа (пока). Нужно найти золотую середину между «вообще не проверяем подпись» и «требуем JWKS которого нет».
Конкретные вопросы:
- Если JWKS недоступен — что проверять ВМЕСТО подписи? (exp, iss, audience?)
- Может ли наш сервис валидировать iss='auth-api' без криптографии?
- Стоит ли делать промежуточный вариант: проверять exp+iss сейчас, а JWKS добавить когда дадут URL?
- Как защититься от подделки токена если подпись не проверяется?
- Нужен ли нам client_secret/shared secret с auth-api?
Ограничения:
- Не предлагай «спросить у команды платформы» — мы и так спросим, но ответа пока нет
- Не предлагай поднять свой Keycloak
- Только практические варианты, которые можно закодить сейчас
- ВЕСЬ ОТВЕТ ОДНИМ БЛОКОМ — без свёрток, без интерактивных элементов