Если при попытке авторизации вы видите ошибку и в консоли встречается текст вроде “Internal user card not found by IAM JWT”, значит система не смогла сопоставить данные пользователя в ЕСИА и на нужной площадке. В этой статье разберём, какие данные ЕСИА чаще всего вызывают сбой, как сверить их с ПСИ стендом, а также что делать при других типичных ошибках при передаче заявок и обработке request/response.
Почему появляется ошибка авторизации
Ошибка авторизации с формулировкой Internal user card not found by IAM JWT обычно означает: в системе не найден пользователь (“user card”), которого ожидает сервис по данным, полученным из токена (JWT). Проще говоря, система не “узнала” человека по тому идентификатору, который пришёл из ЕСИА.
Чаще всего проблема не в пароле и не в доступе к аккаунту, а в несовпадении атрибутов, которыми сервис идентифицирует пользователя или организацию.
Какие данные ЕСИА могут вызвать ошибку авторизации
Проблема чаще всего появляется из‑за несоответствия данных между тестовой средой и стендом. Типичные причины:
- СНИЛС указан по-разному (или вместо тестового внесён реальный/некорректный, или данные отличаются форматом/значениями).
- ФИО в ЕСИА не совпадает с ФИО на ПСИ стенде (встречается добавление организации в отображаемых ФИО на стенде).
- Привязка к организации отличается: ФИО могут быть “похожи”, но пользователь должен быть корректно привязан к той же организации в справочниках.
- В редких случаях причиной становится некорректно заполненный тип заявителя (ФЛ/ЮЛ/ИП) — тогда данные вроде есть, но профиль не совпадает с ожидаемым.
Ключевая мысль: системе нужно, чтобы данные соответствовать друг другу не “на глаз”, а по тем правилам, которые использует связка ЕСИА ↔ стенд.
Как исправить несоответствие данных в ЕСИА и ПСИ стенде
Начните с практического чек-листа сверки. Делайте так, чтобы поля совпали “один в один”:
Проверьте, какие данные заведены в тестовой учетной записи ЕСИА и какие заведены в профиле на ПСИ стенде (раздел безопасности/учётные данные).
Затем проверьте:
- СНИЛС: совпадает ли он.
- ФИО: совпадает ли написание и состав.
- Организация: совпадает ли связка пользователя с организацией.
Важно, что часто различия появляются не из-за сути, а из-за “обвесов” в полях: например, ФИО на стенде может включать добавление организации, и из-за этого выглядит, что “почти одинаково”, но система всё равно считает по-другому.
Если обнаружено расхождение — исправляйте данные именно на ПСИ стенде, чтобы они соответствовать тому, что приходит из ЕСИА.
По каким критериям нужно сравнивать организации при сверке данных
При сверке организации ориентируйтесь на ОГРН.
Если по тестовым контурам в ПГС заведены несколько организаций с одинаковым ОГРН, это тоже нужно учитывать: в таком случае проверьте, к какой именно записи привязан пользователь на ПСИ стенде, и сделайте так, чтобы привязка совпала с ожидаемой.
Почему важно указывать реальный СНИЛС при регистрации тестовой учетной записи в ЕСИА
В тестовых сценариях люди часто хотят “обойтись заглушкой” для СНИЛС. Однако при интеграции авторизации сервис может сверять данные строго по значению.
Поэтому при регистрации тестовой учетной записи в ЕСИА рекомендуется указывать реальный СНИЛС: это снижает риск того, что пользователь появится “в ЕСИА”, но не найдётся корректная карточка на стороне стенда и не будет сопоставлен в токене.
Как проверить соответствие СНИЛС и привязки к организации
Сделайте сверку в таком порядке:
1) Сначала подтвердите СНИЛС: что именно приходит из ЕСИА и что хранится на ПСИ стенде.
2) Затем проверьте ФИО (с учётом возможных добавлений организации).
3) Потом проверьте привязку к организации по ОГРН.
4) Если на стенде есть несколько записей — выберите ту, которая реально соответствует тестовой записи.
Когда эти три блока совпадают, ошибка Internal user card not found by IAM JWT обычно исчезает.
Что делать, если вы тестируете отправку заявок: мониторинг ошибок и количества отправлений
Если проблема всплывает не только на авторизации, а в потоке отправок, важно видеть статистику ошибок. Мониторинг можно вести через dashboard-панель, где собираются коды ошибок и описание проблем по обработке.
Такой подход помогает быстро понять: это ошибка авторизации/идентификации или это проблема параметров, файла, статуса, статуса во времени и т.д.
Коды ошибок при создании и обработке: как читать и что делать
Ниже — практическая логика, которая помогает действовать быстрее: сначала найти причину по коду, затем проверить поля в request, а при необходимости приложить xml запрос/ответ и код ошибки в ситуационный центр.
| Код/ошибка | Суть | Что проверить и как исправить |
|---|---|---|
| Incorrect request parameters | Некорректные параметры request | Убедитесь, что поля имеют корректный формат (например, идентификаторы без лишних символов). |
| User not found | Пользователь не найден в ЕСИА по указанным параметрам | Проверьте, что в запросе заполнены нужные элементы идентификации. Данные должны быть внесены в ЕСИА. |
| Organization not found | Организация-заявитель не найдена | Проверьте заполнение user/orgId/organization и наличие организации в справочниках/ЕСИА. |
| Status not found | Статус не найден | Проверьте записи в справочниках и соответствие статусов ожиданиям системы. |
| Attachment is absent | Нет вложения | Убедитесь, что файл указан корректным идентификатором (FSuuid/datamartUuid) и он реально есть в хранилище. |
| Internal error | Внутренняя ошибка при создании | Обычно требует обращения с кодом ошибки и xml request/response. |
| No unique statuses provided | Статус уже сохранён | Проверьте, что вы не повторно передаёте статус, который уже был записан для заявления. |
| Request date too old | Дата слишком старая | Убедитесь, что request уходит в допустимый интервал (часто ограничение — около 48 часов). |
| Status date in the future | statusDate в будущем | Укажите корректное время и часовой пояс. При отсутствии по умолчанию может проставляться UTC+3. |
| Status date before request date | statusDate раньше requestDate | Проверьте порядок дат, также используйте корректный часовой пояс. |
| System not found | Неизвестная СМЭВ-мнемоника системы | Проверьте используемую мнемонику системы. При повторе нужна заявка в центр. |
| Incorrect eServiceCode or serviceTargetCode | Некорректные коды услуги | Проверьте eServiceCode и serviceTargetCode: они должны быть заведены в базе. |
Во всех случаях, когда проверка полей не даёт результата, требуется сформировать обращение: обычно просят приложить код ошибки и файлы xml запроса request и ответа response.
Частые ошибки “в связке”: почему одна и та же причина может проявляться по-разному
Одна и та же логическая проблема (несоответствие данных) иногда “прячется” под разными симптомами:
- Если неверный пользователь/СНИЛС — вы увидите проблемы идентификации (например, User not found или авторизация не находит user card).
- Если неверная организация — появятся ошибки Organization not found или несоответствия связки.
- Если проблема в данных вложений — будет Attachment is absent.
- Если не совпали статусы — появятся ошибки статуса: Status not found и похожие.
Поэтому важно не только “исправлять текст ошибки”, но и проверять корневые данные: идентификаторы, привязки, статусы и временные параметры.
Как правильно подготовить заявку, если ошибка повторяется
Когда вы делаете обращение в ситуационный центр, старайтесь приложить то, что ускорит анализ:
- код ошибки (точный текст и/или числовой код);
- xml файлы: request и response;
- сведения, какие именно данные передаются (что именно указать в полях и как это соотносится с ЕСИА и стендом).
Это уменьшает время на “угадывание” и позволяет быстрее добраться до причины.
Итог: как быстрее всего решить проблему
Самый практичный путь для ошибки авторизации Internal user card not found by IAM JWT такой:
- Сверьте СНИЛС между тестовой учетной записью ЕСИА и данными на ПСИ стенде.
- Сверьте ФИО с учётом возможных добавлений организации.
- Проверьте привязку к организации по ОГРН и убедитесь, что карточка пользователя привязана к нужной записи.
- Если проблема проявляется в потоке создания заявки, проверьте корректность параметров request, наличие файла (attachment) и соответствие статусов.
- При повторе ошибок — готовьте обращение с кодом ошибки и xml request/response и направляйте в ситуационный центр.
Так вы не просто “уберёте ошибку”, а восстановите правильное сопоставление данных — а значит, и стабильную работу авторизации и обработки заявка/создать в тестовой среде.