Что вам нужно - это аутентификация. Бэкэнд должен аутентифицировать либо внешнее веб-приложение, либо сам пользователь.
Возможно, наиболее распространенным способом является аутентификация интерфейса, что фактически означает, что интерфейс и бэкэнд имеют общий секрет, аутентификация выполняется при каждом вызове, а бэкэнд доверяет интерфейсу. Это может быть достигнуто бесчисленными способами от http basic auth (более https, конечно) до какого-либо механизма ключа api (запросы на подпись и т. Д.). Вам не нужно изобретать колесо, в зависимости от вашей модели использования и угрозы, http basic auth over https вполне может быть достаточно.
Другой способ сделать это - делегировать учетные данные пользователя для бэкэнд-услуг. Это чаще всего достигается путем передачи отдельных входных токенов от пользователя к бэкэнд, эффективно выдавая себя за пользователя, когда внешний интерфейс вызывает бэкэнд-услуги. Возможно, это более безопасно, так как, например, ему не нужен этот уровень доверия между веб-и приложением, но службам все равно нужно доверять компоненту единого входа, который выдал токен. Дело в том, что для противника нет секретов, чтобы украсть (не говоря уже о внешнем сервере, который может быть более легкой целью), поэтому злоумышленнику может быть сложнее выдавать запросы на бэкэнд-услуги, даже если некоторые бэкэнд и/или интерфейсные серверы уже скомпрометированы.
Так что, хотя я думаю, что ответ здесь не в правильном формате, чтобы подробно рассказать о том, как именно сделать эту аутентификацию (действительно, есть много хороших решений, и в каждом случае детали реализации имеют большое значение), по крайней мере концептуально это ваши варианты, я думаю.
Спасибо за ответ, но приложение уже имеет службы аутентификации и авторизации. –
В чем вопрос тогда? Цель аутентификации и авторизации - убедиться, что кто-то является вызывающим и разрешить авторизованным абонентам выполнять действия. Это касается как бэкэнд-услуг, так и внешних приложений. –