Как разобрать ошибку claimsMatchingExpression в Microsoft Entra для GitHub OIDC: сверить issuer, допустимые claims, синтаксис выражения и reusable workflow без расширения доверия.
Локализуйте отказ до обмена токеном
Если портал или API отклоняет claimsMatchingExpression при создании credential, GitHub Actions ещё не участвовал в обмене токеном. Зафиксируйте тип объекта Entra, issuer, audience, languageVersion и полный текст ошибки, скрыв tenant, application ID и имена частных репозиториев. Microsoft описывает flexible FIC как отдельное расширение federatedIdentityCredentials с ограниченным языком выражений. Поэтому не начинайте с разрешений workflow или повторных запусков job: сначала нужно доказать, что сам ресурс и выражение принимаются сервисом.
Проверьте грамматику как четыре поля
Составьте таблицу из claim lookup, оператора, comparand и версии языка. Официальный синтаксис требует форму claims['имя'], оператор matches и строку сравнения в одинарных кавычках; лишний claim или неподдерживаемая конструкция может сделать правило недопустимым. Создайте одно минимальное выражение только для документированного sub, затем добавляйте ровно одно условие за попытку. Не заменяйте точные границы звёздочками ради прохождения валидации: принятое, но слишком широкое правило создаёт отдельный риск доступа.
Сверьте claims с фактической формой GitHub
GitHub документирует стандартные claims и отдельный job_workflow_ref для reusable workflows. Сравните ожидаемую форму sub, repository, ref и job_workflow_ref с токеном тестового workflow, не публикуя сам JWT: достаточно списка имён claims и обезличенных шаблонов значений. Важна роль каждого поля: свойства вызывающего workflow и ссылка на переиспользуемый workflow описывают разные объекты. Если выражение принято, но обмен токеном не проходит, только тогда проверяйте несовпадение issuer, audience и фактических claim values.
Остановитесь на минимально достаточном доверии
Безопасный результат — credential создаётся с узким правилом и тестовый workflow получает доступ только в предусмотренном репозитории или reusable workflow. Отрицательный контроль из соседнего репозитория должен оставаться отклонённым. Не сохраняйте токены, client secrets и полные идентификаторы в тикете. Если документированный минимальный синтаксис отклоняется при неизменном объекте, приложите поддержке UTC-время, correlation ID, languageVersion и обезличенное выражение; не создавайте серию широких credentials как обход ошибки.
Материал подготовлен редакцией VOne с применением ИИ для структурирования; факты вручную сверены с официальной документацией Microsoft и GitHub, а форумная ветка использована только как обезличенный сигнал боли.
Источники и проверка
- Microsoft Learn — Flexible federated identity credentials проверено 2026-07-31
- GitHub Docs — OpenID Connect reference проверено 2026-07-31
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.