Pull to refresh
41
1
Алексей Сушков @AlexeySushkov

Инженер

Send message

Если будет https, то заголовки будут зашифрованными

При установлении mTLS сервер получает сертификат клиента, в котором указаны все IP и адреса, для которых этот сертификат валидин. Соответственно, сервер должен проверить, что запрос пришел с адреса, который есть в сертификате.

Коллега, мы ходим по кругу, предлагаю каждому остаться при своем мнении и делать PoC проекты в соответствии со своими убеждениями, ведь главное – это решение поставленных заказчиком бизнес задач.

Но сначала, лучше самому пройти все по шагам, чтобы понимать как работает и где может косячить готовое решение.
Вот это точно лучшая практика: если не знаешь как сделать, сделай по стандарту!
If Issuer discovery is supported

В этом случае, согласен, адрес issuer должен совпадать с iss в токене. Но discovery процедура входит в список требований из раздела: «15.2. Mandatory to Implement Features for Dynamic OpenID Providers», а Google заявлеяет поддержку только общих требований" «Mandatory to Implement Features for All OpenID Providers», поэтому может не выполнять обязательные требования для discovery.
issuer должен начинаться с https://

В спорных моментах я обычно обращаюсь к стандартам. Смотрим документ 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.
Согласен и OWASP об этом явно говорит в разделе: Sensitive information in HTTP requests
Добавил пункт в список: «API7:2019 Security Misconfiguration»
OWASP рекомендует (Access Control Cheat Sheet) следующие модели обеспечения контроля доступа:

  • Role-Based Access Control (RBAC)
  • Discretionary Access Control (DAC)
  • Mandatory Access Control (MAC)
  • Permission Based Access Control

OWASP склоняется к cookies с реализацией дополнительных механизмов безопасности:
JSON Web Token Cheat Sheet for Java

Если придираться, то HTTPS использует не SSL, а TLS протокол. Но вы, конечно, правы URL шифруется полностью, а IP:Port мы видим в открытом виде, т.к. они используются на другом уровне сетевого стека.
Спасибо за уточнение, поправил, действительно, при использовании HTTPS шифруется весь HTTP запрос, включая URL и параметры, а не шифруется только IP адрес и порт, т.к. это нужно для маршрутизации.
Способы применения OAuth 2.0 и OpenID Connect известны давно, а вот WebAuthn — это свежий протокол прошлого года и его успешные истории мы еще узнаем!

Information

Rating
1,224-th
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity