Javascript-форум (https://javascript.ru/forum/)
-   Серверные языки и технологии (https://javascript.ru/forum/server/)
-   -   backend API Key (https://javascript.ru/forum/server/74772-backend-api-key.html)

olimpset 07.08.2018 12:18

backend API Key
 
Изучаю архитектуру 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 07.08.2018 13:42

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

olimpset 09.08.2018 14:18

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

destus 09.08.2018 15:18

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 09.08.2018 15:34

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

destus 09.08.2018 17:55

olimpset,
Точно

olimpset 09.08.2018 21:04

Я решил сделать проще. Что бы не создавать куча клиентов... будут только те клиенты в Auth0, которые являются личными (сайт, клиент на телефон) и имеют полный доступ. А для тех, кто хочет использовать API, не нужно будет никакой авторизации.
Где то так:
app.route('/api/', (req, res)) //Публичный роут, для внешних запросов.
app.route('/api', checkAccess, (req, res)) //Роут, доступный только для личного 
использования. (из своего сайта, своей программы на телефон).


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

destus 10.08.2018 06:57

Цитата:

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

olimpset 10.08.2018 18:26

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

olimpset 11.08.2018 00:26

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


Часовой пояс GMT +3, время: 10:45.