Как защитить клиентское приложение (реагировать) и обмен данными через API

В случае доменов с перекрестным происхождением вам может потребоваться реализовать CORS и такую ​​безопасность, как черный список. JWT немного отличается, поскольку вы говорите аутентификацию пользователей, которым нужен доступ к вашему api.

Я считаю, что до тех пор, пока вы не включите CORS на своем сервере, все будет в порядке.

Обратите внимание, что это не помешает людям делать такие вещи, как:

https://example.com/api/blah для доступа к части вашего API, если она является общедоступной. По сути, это то же самое, что и ваш внешний интерфейс, потому что клиент обслуживается пользователем, а затем пользователь имеет полный контроль над клиентом. Они могут изменить все экземпляры вызовов api в вашем приложении на другую конечную точку, и вы не сможете их остановить, так же как они могут просто ввести его в строку URL. Любые общедоступные конечные точки на вашем api не должны передавать конфиденциальную информацию.

Если я правильно понял ваш вопрос, вы хотите, чтобы ваш клиент (приложение React) был единственным клиентом, который может получить доступ к вашему серверу.

В качестве решения этой проблемы вам понадобится комбинация CORS и авторизации JWT. Таким образом, я бы предложил использовать строгий CORS, чтобы только домен вашего приложения реагировал на вызов сервера. Для этого я обычно использую модуль npm CORS и источник настроить на моем сервере, или вы также можете сделать это самостоятельно.

var express = require('express')
var cors = require('cors')
var app = express()

var corsOptions = {
  origin: 'http://example.com',
  optionsSuccessStatus: 200 // some legacy browsers (IE11, various SmartTVs) choke on 204 
}

Приведенный выше код позволяет серверу принимать только запросы от example.com или посмотреть на этот код для более динамичного подхода к белому и черному спискам.

Теперь, возвращаясь к JWT, это просто токен шифрования и дешифрования json, который может совместно использоваться в запросах API для аутентификации, а также авторизовывать пользователя.

Например, вы можете хранить такую ​​информацию, как адрес электронной почты, роль и псевдоним пользователя, в JWT и отправлять этот зашифрованный JWT в каждом запросе API, сервер авторизует этот запрос и, если он истинен, пересылает запрошенному API. Этот процесс авторизации и пересылки обычно реализуется с использованием шаблона «перехватчик», в котором промежуточное программное обеспечение (Паспорт oAuth) выполняет проверку и аутентификацию перед каждым вызовом API.

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

Итак, теперь ваше приложение для реагирования должно просто убедиться, что соответствующий токен JWT передается в вызовах API (post / get / put), скорее всего, в заголовке запроса API, у вас может быть вспомогательная служба API, которая делает это за вас, и импортируйте это в компонент, где бы вы ни вызывали API. И ваш сервер узла будет реализовывать шаблон промежуточного программного обеспечения паспорта для авторизации этого JWT и фильтрации неавторизованных запросов.

Если вы реагируете, приложение не имеет логина, JWT также может быть идентификатором клиента, который распознает вашего клиента как законного. И так же, как вход в систему, вы можете заставить приложение реагировать на вызов сервера с данными, такими как секретный идентификатор клиента. Это вернет токен JWT. ИЛИ вы можете предварительно сгенерировать токен JWT, и вы отреагируете на него, когда приложение будет загружено в первый раз, и, установив TTL и другую конфигурацию, вы можете проверить, является ли клиент, который обращается к вашему серверу, старый или новый или какой-либо другой фальшивый клиент.

HTH