backend API Key

[olimpset]

Изучаю архитектуру Rest API и тут встал вопрос. Есть два проекта (Node - backend и Angular (ts) - frontend). Они независимы друг от друга (на разный VPS серверах даже). Так вот, как идентифицировать запросы ssl (post, get, put, delete) от фронтенда. Ведь по логике, без идентификации из любого места можно будет делать запросы к API. И тут я подумал про API Keys, делать JWT ключ с секретом, который знает бэкенд, ключ с бесконечным сроком жизни. Или второй вариант, воспользоватся сервисом Auth0, читал что можно такое организовать.
Дело в том, что нужно разграничить роли. Естественно, если это доверенный, нами разработанный фронтенд, то он имеет больше прав и соответственно ему доступны все запросы API. В то время, если другой разработчик использует API, то доступ у него будет не ко всем роутам API. Хороша ли идея, воспользоватся в данном случае токенами jwt и хранить их в БД, если нужно отозвать API Key? Информации по данной теме немного нашел.

[destus]

olimpset,
Вот полный пример реализации на ноде защищенного API с использованием Auth0 https://scotch.io/tutorials/building...rn-backend-api

[olimpset]

Так, с Auth0 разобрался. Но есть ещё один вопрос. Яя значит создаю клиента в Auth0 (для своего сайта), и создаю ещё одного клиента, с урезанными правами, для тех, кто будет пользоваться моим API. Потом в БД буду генерировать API Key. И будут посылаться запросы к этим ключом от клиентов, и сервер будет запрашивать access токен у Auth0, используя для этого только один клиент, который с ограниченным правами. Правильно ли я мыслю? В двух словах. Нужно с помощью Auth0 сделать архитектуру: Мой клиент (сайт) с Макс правами, и клиент для остальных, внешних запросов к API, с ограниченными правами.

[destus]

olimpset,
Вы точно с Auth0 разобрались? Никакие API key вы не генерируете.
Вы создаете пользователей, наделяете их правами (указывая к каким scope он относится) и всё. Далее клиент посылает запрос на Auth0 сервис с необходимыми данными (NON_INTERACTIVE_CLIENT_ID, NON_INTERACTIVE_CLIENT_SECRET, grant_type, audience), Auth0 в ответ отсылает клиенту access_token, который он должен будет послать на ваш сервер в заголовке Authorization. Далее express-jwt модуль его расшифрует и в req.user отдаст вам пользователя. Теперь вы можете проверить его scope и решить, давать ли ему права на нужный URL.

[olimpset]

Это всё я понял и сделал, это работает. Но допустим, если много вебмастеров (допустим 10) захочет интегрировать на свой сайт некоторые функции моего API, тогда получается, для каждого нужно создать отдельный клиент в Auth0 (в сумме 10) и каждому грубо говоря, скинуть секрет его, id, и т.п, далее каждый вебмастер будет запрашивать свой access_token, посылая запрос Auth0. Правильно схему понял?

[destus]

olimpset,
Точно

[olimpset]

Я решил сделать проще. Что бы не создавать куча клиентов... будут только те клиенты в Auth0, которые являются личными (сайт, клиент на телефон) и имеют полный доступ. А для тех, кто хочет использовать API, не нужно будет никакой авторизации.
Где то так:

app.route('/api/', (req, res)) //Публичный роут, для внешних запросов.
app.route('/api', checkAccess, (req, res)) //Роут, доступный только для личного 
использования. (из своего сайта, своей программы на телефон).

Как мне кажется, это лучше, чем создавать много клиентов. Имеет ли место быть такое решение?

[destus]

Имеет ли место быть такое решение?

Да

[olimpset]

Отлично. Теперь назревает логический вопрос. Авторизацию реализовывать на бэкенд (с помощью passport) или же теперь можно создать в Auth0 клиент с типом SPA, а не машина к машине, прикрутить это все и на сервер при запросе API, отправлять токен и на сервере уже проверять по токену, авторизирован ли или нет ? В данном случае, на сервере не будет ничего лишнего выполнятся. Только запросы и проверка авторизации. А сама авторизация на клиенте.

[olimpset]

Неоднократно читал, что сам процесс авторизации в случае OpenID, (идентификация наверное на сервере должна быть) должен проходить на клиенте (фронтенд), и потом серверу вместе с запросами прикреплять access_token, и задача сервера лишь проверить это токен и решить, авторизирован аль нет. Теперь сомневаюсь, что нужно этот процесс (авторизацию) на сервере делать.
Как считаете?