Требуется ли проверка идентификаторов OpenID Connect id_token и access_token, если они получены веб-сервером?

Вы всегда должны проверять токены и применять хорошо известные шаблоны проверки для токенов. Потому что в противном случае вы открываете свою архитектуру для различных уязвимостей. Например, у вас есть проблема с человеком посередине, если хакер перехватывает ваше личное общение с сервисом токенов.

Кроме того, большинство библиотек выполнят проверку автоматически, поэтому проверка не является проблемой.

При разработке систем идентификации вы должны следовать лучшим практикам и различным лучшим текущим практикам, потому что именно этого ожидают от вас пользователи системы.

Как клиент, вы используете HTTPS для получения открытого ключа от IdentityServer, поэтому вы знаете, что вы получили от нужного сервера. Чтобы добавить дополнительные уровни безопасности, вы также можете использовать сертификаты HTTPS на стороне клиента, чтобы IdentityServer выдавал токены только клиентам, которые проходят проверку подлинности с помощью сертификата.

Таким образом, «человек посередине» практически невозможен. Однако в центрах обработки данных в бэкэнде вы иногда не используете HTTPS везде внутри компании. Часто TLS завершается через прокси, вы можете узнать об этом здесь

Когда вы получаете ID-токен, вы обычно создаете на его основе сеанс пользователя. И да, поскольку токен пересылается по более безопасному обратному каналу, вы можете быть в безопасности с этим. Но до сих пор многие атаки происходят изнутри, и чтобы хорошо работать в соответствии со всеми передовыми практиками, вы должны проверить их, как подпись, так и утверждения внутри токена (срок действия, эмитент, аудитория ...).

Для токена доступа важно, чтобы API, который его получает, действительно проверял его в соответствии со всеми передовыми практиками, потому что любой может отправлять запросы с токенами на него.

Кроме того, это интересно учиться :-)

ps, это видео является хорошей отправной точкой.