Как лучше сделать закрытое REST API?

Question

[cixazixaye]

Как лучше реализовать закрытый REST API? Отправлять при каждом запросе токен или просто через CORS? Или есть более элегантное решение?

Как вообще в будущем разделить API для всех и для себя? Например, какие-то методы оставить для себя и запретить ими пользоваться другим.

Answer 1

[xmoonlight]

CORS не имеет ничего общего с API. Т.к. это - браузерная технология и используется для скриптов внутри браузеров.

Простой принцип разделения:
1. Для всех - список параметров без ключа.
2. Для себя - список параметров с неким ДИНАМИЧЕСКИМ ключом (токен подписи) и формулой его генерации, которая известна только Вам.

Теперь, защита от перехвата (лучше делать, даже если есть SSL):
1. На сервере храним формулу генерации подписи запроса на основе входных параметров запроса к API и временной метки.
2. При обращении к функциям "закрытого" API (для личных целей) Вы формируете подпись запроса, предварительно СИНХРОНИЗИРУЯ время с серверным, и затем, согласно формуле, отсылаете на сервер.
3. Сервер, зная формулу делает тоже самое и сверяет значения присланной и полученной (по той же формуле на стороне сервера) подписи: если они не совпадают ИЛИ просрочена ИЛИ это дубликат - сервер запрос к API отклоняет, иначе - запрос исполняется.
4. Сервер кэширует запрос на время погрешности синхронизации, чтобы предотвратить повторное использование идентичного запроса посредством MiTM-перехвата.

Answer 2

[al_gon]

JSON_Web_Token

Answer 3

[Рамиль]

Вам нужно смотреть в сторону OAuth авторизации (не путать с аутентификацией).
CORS вряд ли вам поможет. Так как он дает привелегии для доменов, а не для пользователей.

Answer 4

[Константин Б.]

Для этого используют middleware и JWT

Answer 5

[Фади Хадж]

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

Comments

[xmoonlight]

бред пишите: если Вы подпись запроса не сформируете верным образом, то никакая документация не спасёт...

[Фади Хадж]

xmoonlight: Видимо, Вы меня не так поняли.

[xmoonlight]

Fadi Hadzh: Я говорил про это:

а если доступное из браузера или скажем приложения, то это API перестает быть закрытым, а становится попросту недокументированным.

[Фади Хадж]

xmoonlight: Рассмотрим пример API для мобильного приложения. Проведя реверс-инжиниринг можно найти методы и схемы запросов, однако данное API разработчики, вероятно, считают закрытым, но это не так.

[xmoonlight]

Fadi Hadzh: Предлагаю Вам не путать понятия:
1. Обезличенный/публичный доступ к открытому API - когда всё открыто и не просят ввода пользователя (или токена) в запросах к API.

2. Авторизованный доступ к открытому недокументированному API (то, что Вы описали) - единая формула подписи для всех запросов, меняются только параметры клиента (username, UUID и т.д.). Обычно используют в клиентских приложениях, которые можно скачивать/устанавливать и/или просматривать их логику и т.д.

3. Авторизованный доступ к закрытому API - уникальная формула подписи запросов, включая параметры клиента и известная только одному клиенту. Формула никогда не хранится и не передаётся 3-й стороне (например, не размещается в приложении).

Касательно п.2:
Методы и схемы - найти можно. А вот выполнить валидный запрос к API без формулы и всех параметров - так просто - не удастся. Я не спорю, что можно попробовать всё продебажить и получить эту формулу(+ключи) через реверс-инжиниринг из скомпилированного кода программы. Но это очень трудоёмко, а проапдейтить приложение в маркете - это 2-3 часа максимум.

То, чем пользуется приложение - это открытое API с авторизованным доступом.
Закрытое API - это когда есть API, но нет формулы подписи запросов, которая доставляется отдельно каждому клиенту и является уникальной для каждого клиента.

Формула подписи запросов - это динамический токен, он также может быть с какой-либо привязкой к любому однозначно проверяемому параметру: подсети, IP-адресу, userID любого "облачного" сервиса, домену, e-mail, устройству, стране, городу и т.д.
Также, такой токен может быть как с определённым сроком действия, так и безлимитный.

[Фади Хадж]

xmoonlight: Понял Вас. Спасибо что поправили.