Есть ли способ защитить ключ API на странице внешнего интерфейса?

Question

Мой сервис позволяет преобразовывать любые документы HTML в PDF с помощью запроса POST.Он в основном используется на серверной части сервера моего клиента, и поэтому ключ API, используемый для связи, остается закрытым.

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

Моя главная проблема здесь - это безопасность.Если мой клиент добавит запросы XHR POST, содержащие ключ API, кто-то может взять этот ключ API и использовать его для своих собственных целей и злоупотреблять учетной записью моего клиента.

Я мог бы фильтровать по домену, но это легко подделка, так что это невозможно.

Мне было интересно, есть ли способ вызвать частную службу и быть идентифицированным, не рискуя украсть ее личность со стороны клиента (клиента)

Answer 1

На мой взгляд, вы можете использовать токены JWT.На основе имени пользователя, пароля или любой другой информации вы можете генерировать уникальные токены jwt для разных пользователей.Любой может расшифровать эти токены jwt, но не уникальный маркер безопасности.

Если вы хотите повысить безопасность токенов, используйте JWE, зашифрованные веб-токены.

Подробнее об этих схемах можно узнать по адресу https://medium.facilelogin.com/jwt-jws-and-jwe-for-not-so-dummies-b63310d201a3

Answer 2

Предполагая, что вы используете систему типа OAuth, в этом случае используйте механизм токенов доступа, который обеспечивает доступ к частному API / данным пользователя от имени пользователя (клиента) без предоставления его / ее учетных данных или ключа API (аутентификация).ключ), также токен доступа может быть истек в зависимости от времени / использования.

Пример: токен доступа генерируется для одной конечной точки, которая может быть конечной точкой преобразования HTML и срок действия которой истечет после завершения действия.

https://auth0.com/docs/tokens/access-token

И послепост в блоге будет полезен для построения вашей системы аутентификации https://templth.wordpress.com/2015/01/05/implementing-authentication-with-tokens-for-restful-applications/

Answer 3

Хеширование - это достойный вариант, и его нужно делать в любом случае, но для полностью безопасного метода, который не будет слишком сложным, вы можете просто абстрагироваться от ключа авторизации / API, создав собственный API для взаимодействия с API.,Таким образом, вы можете ограничить виды действий, которые можно выполнить с помощью ключа API, а также полностью скрыть ключ API от пользователя

Answer 4

нет хорошего способа сделать интерфейсное безопасное хранилище, но я рекомендую:

- это API, который использовал HMAC-подписывание запросов в сочетании с аутентификацией OAuth.Ключ API на самом деле является ключом подписи.Ключ не передается.Ключ API все еще можно найти во внешнем интерфейсе, но он становится бесполезным, потому что вам все еще нужен токен OAuth для отправки действительного запроса.

Я знаю, что пользователям придется войти в систему, но вы можете увидеть это какПреимущество, потому что, по крайней мере, вы можете регистрировать, кто использует приложение, получая информацию из oauth.

пожалуйста, рассмотрите внутреннее безопасное хранилище!

Answer 5

Если вы предоставляете этот субаренд для аутентифицированных пользователей, то довольно просто дать им уникальные ключи (что-то, что хэширует их идентификатор пользователя или сеанс с ключом API и начальной меткой времени, и проверяет его / регистрирует его / ищетскоты до доступа к API).Если вы делаете это в открытой сети, без какой-либо аутентификации пользователя, то ограничение скорости действительно становится очень сложным.Обычно для создания анонимного профиля, который получает временный ключ во внешнем интерфейсе, вы хотите использовать комбинацию хеш-сессий, IP-адреса, операционной системы и данных браузера.Один довольно надежный способ сделать это - заставить пользователей пройти через CAPTCHA, прежде чем обслуживать временный ключ, который позволяет им ограниченное количество использований постоянного ключа.Любой пользователь, чей ip / browser / session соответствует существующим атрибутам известного клиентского ключа, шунтируется на него (и получает возможность пропустить CAPTCHA);любой, кто не соответствует существующему профилю, получает CAPTCHA.Это делает вас менее привлекательной целью для подмены.Вдобавок ко всему, вы всегда должны ограничивать скорость всего этого, в пределах разумного количества посещений в день, исходя из того, какой трафик вы ожидаете (или можете себе позволить), чтобы у вас не было никаких сюрпризов.Это минимальный уровень защиты, который вы хотели бы получить, если бы деньги вашего клиента находились на линии каждый раз, когда используется их ключ API.Потребуется простая база данных для хранения этих «профилей», отслеживания использования, проверки на наличие зверюшек и поддержки действующих на данный момент клиентских ключей.Срок действия клиентских ключей всегда должен истекать регулярно - либо с разницей во времени, когда они были созданы, либо с обычным процессом cron, либо с максимальным количеством использований и т. Д.

Еще одна вещь, которую я часто делаю, это ограничение скоростина основе кривой.Если я считаю целесообразным 5 использований в минуту, например, то после 5 использований в минуту от сеанса каждое использование добавляет задержку доли секунды * количество использований в последнюю минуту в квадрате перед даннымиобслуживается.

Лучшим ответом было бы оставить все это за системой входа в систему и обезопасить , что .