Комментарии 26
Типичный проект PoC (Proof of Concept) состоит из клиента с GUI, сервера c бизнес логикой и API между ними.
Что, простите? Вы вообще в курсе, что такое PoC?
В статье рассматривается PoC, построенный на веб технологиях в архитектуре клиент-сервер. Перечисленный набор компонентов является стандартным для данного класса PoC.
Вы меня извините, но набор компонентов "клиент и сервер" "является стандартным" для "класса архитектур клиент-сервер", при чем тут PoC?
PoC обычно делается как раз чтобы обкатать тот или иной выбор, а вы свой выбор навязали заранее, в чем тут PoC?
И я предлагаю не PoC, а стандартную основу или заготовку для реализации любых PoC, которые планируется реализовать в клиент-серверной архитектуре с использованием веб-технологий.
Эмм… Ну вот мне ваша "стандартная заготовка" вообще не подойдет, даже если я буду делать что-то для веб, потому что у меня полностью другой стек. Ну и какой смысл тогда?
Не говоря о том, что обычно все мои PoC — это проверка технологии, поэтому мне это дважды не сдалось.
Ведь не важно, какой стек технологий используются, в любом случае, нужно обеспечивать безопасность API, реализовывать аутентификацию пользователей, делать структуру базы данных, защищаться от DoS, логировать, мониторить и т.д.
В этом вы как раз не правы. Весь смысл PoC в том, чтобы проверить конкретное предположение. Вам может быть не нужна безопасность, или мониторинг, или аутентификация, или еще что-то.
При этом ваши "лучшие практики", во-первых, спорно реализованы, и во-вторых, полностью зависят от ваших технологий. Если бы я делал PoC для веб-приложения, я бы забил и на DoS, и на мониторинг внутри приложения, потому что для этого есть прекрасный инструментарий снаружи. А приложение пусть бизнесом занимается.
В best practices для PostgreSQL регулярно встречал (в том числе здесь на хабре) рекомендации не использовать ORM-ки, так что применение Sequelize тоже неоднозначное решение.
«Рекомендации не использовать ORM-ки» не встречал. Могу предположить, что возможная причина таких рекомендаций может быть в неоптимальной работе ORM. Но оптимизация — тоже относится к промышленной эксплуатации системам, к которым предьявляются требования по производительности и времени отклика.
Аутентификация с помощью Google Account (Token-Based Authentication)
Кстати, не надо использовать (и тем более предлагать использовать в качестве шаблона) OAuth 2, когда уже есть OIDC с дискавери и прочей нормальной валидацией. Тогда вы и issuer не забудете провалидировать, и адрес JWK Set хардкодить не придется.
accounts.google.com/.well-known/openid-configuration
В статье описан и в заготовке используется именно OpenID Connect от Google.
… только вы не валидируете (точнее, нигде не описываете, как правильно валидировать) OIDC identity token. А учитывая, что вы делаете аутентификацию, вам не нужен response_type=code, а нужен вам id_token или code id_token, который будет намного проще.
• Проверяем, что id_token подписан Google. Для этого нужен открытый ключ от Google. Google хранит актуальную аутентификационную информацию по стандартному адресу: accounts.google.com/.well-known/openid-configuration. Адрес сертификатов находится в параметре «jwks_uri».
• В токене параметр iss должен содержать адрес Google: accounts.google.com
• Параметр aud должен быть равен Client ID нашего приложения, который получен раннее на сайте Google.
• Параметр exp содержит время окончания действия токена, оно должно быть не просрочено.
Спасибо за замечания, согласен, что алгоритм валидации токена важен, поэтому добавил его в статью:
… в качестве "хорошей практики" намного полезнее взять готовое решение, которое есть для каждой достаточно развитой платформы. Тогда не будет утверждений вида "в токене параметр iss должен содержать адрес Google: accounts.google.com" (нет, не должен).
А еще если взять готовое решение, будет, собственно, все равно, гугль ли там, или любой другой OIDC.
iss — The Issuer Identifier for the Issuer of the response. Always accounts.google.com or accounts.google.com for Google ID tokens.
Не совсем все равно
Брать готовое решение хорошо, когда понимаешь что происходит под капотом
Понимать — одно. А делать самому — другое.
iss — The Issuer Identifier for the Issuer of the response. Always accounts.google.com or accounts.google.com for Google ID tokens.
Вот только вы умудряетесь не видеть, что в вашем тексте — ошибка (issuer должен начинаться с https://). А готовое решение, которому вы скормите стартовый путь, и которое самое пройдет по дискавери и так далее, этого не пропустит.
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.
В спорных моментах я обычно обращаюсь к стандартам. Смотрим документ OpenID Connect Core 1.0
… а смотреть надо на issuer из OIDC Discovery. Он обязан совпадать с тем, который в выданном токене. Не совпадает — нафиг такой токен. Начнете встраивать special cases для гугля — потонете в проверках, а безопасно ли это.
Вот вам цитата из стандарта:
issuer
REQUIRED. URL using the https scheme with no query or fragment component that the OP asserts as its Issuer Identifier. If Issuer discovery is supported (see Section 2), this value MUST be identical to the issuer value returned by WebFinger. This also MUST be identical to theissClaim value in ID Tokens issued from this Issuer.
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.
Он много чего может не выполнять, но де факто выполняет. Поэтому лучше действовать по стандарту, и всем так будет лучше.
… и лучше всего — возьми готовое решение, которое делает по стандарту, чтобы не думать, какие (важные) детали стандарта ты пропустил.
В том-то и дело, что нет. Мы говорим о PoC-проектах. В PoC-проектах надо потратить максимум ресурсов на тот концепт, который вы исследуете, а не на инфраструктуру, которая стабильная и понятна. Поэтому максимум, который можно выкинуть, надо выкинуть, а то, что нельзя выкинуть, заменить на готовые решения. А разбираться в них точно не надо, потому что они не имеют отношения к вашему концепту.
Best practices для клиент-серверного проекта PoC