Как обеспечивается защищенность между фронтэндом и бекэндом

где хранить secret key в приложении на JS?

Токен? В localstorage например, или в куках, или я не правильно понял вопрос)

Я так понял ТС боится, что его оттуда вынут нехорошие люди.

https://www.ibm.com/developerworks/ru/library/iot-trs-secure-iot-solutions3/i...

Какая разница какой фронт будет использован для доступа к твоему апи?

Закрыть доступ полностью не выйдет (если фронт браузерный) а так аппаратные токены к твоим услугам.

но где хранить secret key в приложении на JS?

Идиот. Всё что доступно JS доступно для юзера. Внедриться в клиентский js можно через аддоны браузера которые не контролируются клиентским js.

Токен в локалсторажд.

Если требуется просто защита от кастомных фронтедов для конечного пользователя, тогда нужно настроить cors

... точно так-же как и в защите соединений для веб в силу отсутствия существенных отличий.

JWT это популярное решение для работы с API - это как бы не городить сессию, но куки остаются конечно. Без кук только урлы, «доверенности» и всякие разные другие способы трекинга" )))

Как закрыть api для всех, кроме фронтэнда?

Зачем закрывать апи, если без авторизации по нему никто ничего не получит?

Вопрос был именно про авторизацию. Просто не правильно сформулировал.

То есть, просто попав на сайт, клиент сразу получает токен? И со стороны приложения-клиента никаких действ кроме сохранения нет?

То есть, просто попав на сайт, клиент сразу получает токен?

Заходим на фронтенд, авторизуемся, отправляем данные авторизации на бекенд, если все верно, то получаем токен от бекенда, токен сохраняется на клиенте в локалсторадже и последующие запросы идут с токеном в хедере.

Если токена нет/неверный, то бекенд отдает ошибку и фронтенд красиво ее отображает.

Вопрос был именно про авторизацию. Просто не правильно сформулировал.

Ну так это азы же. Регистрируется пользователь, придумывает себе логин и пароль. Потом авторизуется по ним и получает набор символов, представляющих его текущую сессию, - по нему сервер и отличает легального данного юзера от всех остальных. Ну и всё это по https, само собой.

То есть, просто попав на сайт, клиент сразу получает токен?

Фактически, да, есть такой момент. Клиент, попав на сайт по https, устанавливает защищённое соединение. Но это не по теме и иерархически уровнем ниже, чем то, о чём мы беседуем.

ща барузеры по-умолчанию требуют. по крайней мере fetch api