#node.js #security #authentication #google-cloud-platform
#node.js #Безопасность #аутентификация #google-облачная платформа
Вопрос:
Мы находимся в процессе разработки мобильного (собственного) приложения и рассматриваем, как мы должны выполнять аутентификацию пользователей. Большая часть информации, которую я нашел, касалась веб-приложений и / или сторонних приложений, получающих доступ к общедоступным API. Поэтому OAuth 2 рекомендуется использовать большую часть времени.
Поскольку мы разрабатываем приложение, а наш API не является общедоступным, похоже, что поток учетных данных пароля владельца ресурса OAuth 2 может быть вариантом, но в соответствии с oauth.net это больше не рекомендуется.
Мы используем Google App Engine (с Node.js ) и конечные точки облака (не уверен, понадобятся ли конечные точки, поскольку это частный API, но это другой вопрос) в качестве серверной части, и обе Firebase Auth и Auth0 имеют встроенную поддержку в конечных точках. Однако у нас есть некоторые особые требования, которые не делают эти сервисы подходящими (например, шведский BankID).
Какие еще варианты существуют при аутентификации пользователей? Можем ли мы написать приложение в App Engine для проверки учетных данных пользователей в нашей базе данных, а затем отправить обратно JWT (облачные конечные точки поддерживают пользовательские методы аутентификации, если они используют JWT)? Было бы безопасно сделать это самостоятельно? Я нашел некоторые Node.js библиотеки для аутентификации, но большинство из них, похоже, нацелены на веб-приложения. Есть ли какие-либо, которые подходят для интерфейса собственного приложения?
Комментарии:
1. Я нахожусь в аналогичной ситуации. Мы используем конечные точки GAE Standard и Google Cloud. В нашем веб-приложении мы аутентифицируем пользователей с помощью email / pwd. Мы хотели бы использовать это и для мобильных приложений. Мы не хотим использовать OAuth, а вместо этого используем нашу схему email / pwd для аутентификации пользователей. Ближайшая вещь, которую я могу найти подходящей, — это использование пользовательского метода для аутентификации пользователей: cloud.google.com/endpoints/docs/openapi /. … Однако в нем мало деталей реализации.
2. Я согласен, что должно быть больше документации. В конечном итоге мы, вероятно, создадим метод POST в App Engine, который проверяет имя пользователя / пароль, а затем создает JWT, который отправляется обратно и сохраняется в приложении. Затем этот JWT добавляется в заголовок каждого запроса, отправляемого конечным точкам. После этого я не уверен на 100%, что делать дальше, поскольку я раньше не использовал конечные точки. Но конечная точка должна проверять токен более или менее автоматически, если все настроено правильно
Ответ №1:
Для аутентификации, да, вы можете выполнить проверку самостоятельно в своей базе данных и предоставить или нет JWT в соответствии с результатом аутентификации.
Однако, и это очевидно, эта служба аутентификации должна быть общедоступной (потому что она предназначена для аутентифицированных пользователей, не прошедших проверку подлинности!). И, таким образом, вы можете подвергаться атакам на эту службу. И поскольку это служба аутентификации, в случае сбоя службы никто больше не сможет войти в систему или, что еще хуже, если у вас есть нарушение безопасности, ваша пользовательская база данных может быть украдена.
Вот почему, чтобы использовать существующие службы со всеми средствами защиты, все ресурсы (люди, мониторинг, автоматическое реагирование, высокая доступность, …), развернутые для управления большим количеством угроз. Firebase auth, Auth0, Okta (…) являются подходящими поставщиками, но я не знаю ваших требований к шведскому языку, и вы можете не избежать конкретных разработок
Комментарии:
1. Спасибо за ваш вклад! Шведский BankID — это система электронной идентификации. Может быть, стоит использовать что-то вроде Auth0, чтобы не иметь дело с возможными уязвимостями безопасности
2. Да, это мой лучший ответ. Для этого есть эксперты и специальные команды.