При установлении mTLS сервер получает сертификат клиента, в котором указаны все IP и адреса, для которых этот сертификат валидин. Соответственно, сервер должен проверить, что запрос пришел с адреса, который есть в сертификате.
Коллега, мы ходим по кругу, предлагаю каждому остаться при своем мнении и делать PoC проекты в соответствии со своими убеждениями, ведь главное – это решение поставленных заказчиком бизнес задач.
В этом случае, согласен, адрес issuer должен совпадать с iss в токене. Но discovery процедура входит в список требований из раздела: «15.2. Mandatory to Implement Features for Dynamic OpenID Providers», а Google заявлеяет поддержку только общих требований" «Mandatory to Implement Features for All OpenID Providers», поэтому может не выполнять обязательные требования для discovery.
В спорных моментах я обычно обращаюсь к стандартам. Смотрим документ OpenID Connect Core 1.0
С одной стороны, вы правы и https обязателен:
2. ID Token
iss — Issuer Identifier for the Issuer of the response. The iss value is a case sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components.
Но с другой стороны, для Google сделано исключение:
15.6.2. Google «iss» Value
Implementers may want to be aware that, as of the time of this writing, Google's deployed OpenID Connect implementation issues ID Tokens that omit the required https:// scheme prefix from the iss (issuer) Claim Value.
Брать готовое решение хорошо, когда понимаешь что происходит под капотом. Должен:
iss — The Issuer Identifier for the Issuer of the response. Always accounts.google.com or accounts.google.com for Google ID tokens.
Спасибо за замечания, согласен, что алгоритм валидации токена важен, поэтому добавил его в статью:
• Проверяем, что id_token подписан Google. Для этого нужен открытый ключ от Google. Google хранит актуальную аутентификационную информацию по стандартному адресу: accounts.google.com/.well-known/openid-configuration. Адрес сертификатов находится в параметре «jwks_uri».
• В токене параметр iss должен содержать адрес Google: accounts.google.com
• Параметр aud должен быть равен Client ID нашего приложения, который получен раннее на сайте Google.
• Параметр exp содержит время окончания действия токена, оно должно быть не просрочено.
В статье описан и в заготовке используется именно OpenID Connect от Google. В результате работы алгоритма возвращается id_token, с помощью которого происходит аутентификация. Другое дело, что функциональность discovery в заготовке, действительно, не реализована, но сделать ее при необходимости несложно, ведь Google поддерживает стандартный endpoint с информацией об остальных endpoints: accounts.google.com/.well-known/openid-configuration
Сама заготовка сделана на конкретном стеке технологий: SQLite + Express.js + Vue.js + Node.js. Но статья больше не про технологии, а лучшие практики. Ведь не важно, какой стек технологий используются, в любом случае, нужно обеспечивать безопасность API, реализовывать аутентификацию пользователей, делать структуру базы данных, защищаться от DoS, логировать, мониторить и т.д.
Согласен, что из введения не очень понятны ответы на ваши вопросы. Описанное в статье техническое решение, конечно, не PoC, а стандартное веб-приложение. И я предлагаю не PoC, а стандартную основу или заготовку для реализации любых PoC, которые планируется реализовать в клиент-серверной архитектуре с использованием веб-технологий. Чтобы эта заготовка стала настоящим PoC в какой-нибудь области (IoT, телеком, финансы, медицина) к ней, надо прикрутить функциональность взаимодействия с внешними системами.
Спасибо за комментарий, в статье я, действительно, не уделяю внимание вопросу запуска приложений в промышленную эксплуатацию. Это тема для отдельного раздела или статьи.
«Рекомендации не использовать ORM-ки» не встречал. Могу предположить, что возможная причина таких рекомендаций может быть в неоптимальной работе ORM. Но оптимизация — тоже относится к промышленной эксплуатации системам, к которым предьявляются требования по производительности и времени отклика.
В статье рассматривается PoC, построенный на веб технологиях в архитектуре клиент-сервер. Перечисленный набор компонентов является стандартным для данного класса PoC.
Если придираться, то HTTPS использует не SSL, а TLS протокол. Но вы, конечно, правы URL шифруется полностью, а IP:Port мы видим в открытом виде, т.к. они используются на другом уровне сетевого стека.
Спасибо за уточнение, поправил, действительно, при использовании HTTPS шифруется весь HTTP запрос, включая URL и параметры, а не шифруется только IP адрес и порт, т.к. это нужно для маршрутизации.
Если будет https, то заголовки будут зашифрованными
При установлении mTLS сервер получает сертификат клиента, в котором указаны все IP и адреса, для которых этот сертификат валидин. Соответственно, сервер должен проверить, что запрос пришел с адреса, который есть в сертификате.
В этом случае, согласен, адрес issuer должен совпадать с iss в токене. Но discovery процедура входит в список требований из раздела: «15.2. Mandatory to Implement Features for Dynamic OpenID Providers», а Google заявлеяет поддержку только общих требований" «Mandatory to Implement Features for All OpenID Providers», поэтому может не выполнять обязательные требования для discovery.
В спорных моментах я обычно обращаюсь к стандартам. Смотрим документ OpenID Connect Core 1.0
С одной стороны, вы правы и https обязателен:
2. ID Token
iss — Issuer Identifier for the Issuer of the response. The iss value is a case sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components.
Но с другой стороны, для Google сделано исключение:
15.6.2. Google «iss» Value
Implementers may want to be aware that, as of the time of this writing, Google's deployed OpenID Connect implementation issues ID Tokens that omit the required https:// scheme prefix from the iss (issuer) Claim Value.
iss — The Issuer Identifier for the Issuer of the response. Always accounts.google.com or accounts.google.com for Google ID tokens.
Не совсем все равно
• Проверяем, что id_token подписан Google. Для этого нужен открытый ключ от Google. Google хранит актуальную аутентификационную информацию по стандартному адресу: accounts.google.com/.well-known/openid-configuration. Адрес сертификатов находится в параметре «jwks_uri».
• В токене параметр iss должен содержать адрес Google: accounts.google.com
• Параметр aud должен быть равен Client ID нашего приложения, который получен раннее на сайте Google.
• Параметр exp содержит время окончания действия токена, оно должно быть не просрочено.
accounts.google.com/.well-known/openid-configuration
«Рекомендации не использовать ORM-ки» не встречал. Могу предположить, что возможная причина таких рекомендаций может быть в неоптимальной работе ORM. Но оптимизация — тоже относится к промышленной эксплуатации системам, к которым предьявляются требования по производительности и времени отклика.
Добавил пункт в список: «API7:2019 Security Misconfiguration»
JSON Web Token Cheat Sheet for Java