Существует некорректно работающий с OpenID Connect «совместимый» iDP (на данный момент он должен оставаться безымянным) - он выдает ошибку при использовании области видимости openid и любого response_type, который включает id_token. Это определенно ошибка, о которой сообщалось.
Тот же iDP также возвращает id_token в неявном потоке, когда область видимости включает openid, а response_type является просто «токеном». Это приводит к сбоям в работе широко используемого пакета npm oidc-client, который сообщает об ошибке «Не ожидается id_token в ответе» - что, согласно спецификации OIDC, является строго правильным.
Но тут возник интересный вопрос:
Учитывая базовую предпосылку из раздела 1 спецификации OIDC:
OpenID Connect реализует аутентификацию как расширение процесса авторизации OAuth 2.0. Клиенты запрашивают использование этого расширения путем включения значения области openid в запрос авторизации.
и этот раздел 3.2.2.1 говорит
ПРИМЕЧАНИЕ. Хотя OAuth 2.0 также определяет значение типа ответа токена для неявного потока, OpenID Connect не использует этот тип ответа, поскольку токен идентификатора не возвращается.
должно ли поэтому быть ошибкой их использование вместе? Или тот факт, что openid находится в области видимости, должен приводить к тому, что реализация по умолчанию «добавляет» id_token к response_type неявного потока?
