Хороший подход для схемы токена веб-API?

Question

Я работаю над REST API для веб-приложения, которое до сих пор мы разрабатывали для нескольких сопутствующих приложений. Теперь, когда мы смотрим на открытость для внешних разработчиков, мы хотим добавить токены в API, чтобы помочь идентифицировать, кто делает запросы, и в целом, чтобы помочь управлять его использованием. На данный момент мы используем https и базовую аутентификацию для аутентификации пользователя в API.

Схема токенов, которую мы обсуждали, будет очень простой, когда каждому разработчику будет назначено 1 или более токенов, и эти токены будут передаваться в качестве параметра с каждым запросом.

У меня вопрос: если вы делали что-то подобное раньше, как вы это делали (делали ли вы более или менее, как вы относились к безопасности и т. Д.) И есть ли у вас какие-либо рекомендации?

Спасибо!

Answer 1

Во-первых, вы можете захотеть взглянуть на http://OAuth.net. В зависимости от ваших сценариев использования, он может обеспечить необходимую вам безопасность.

Что касается токена, то это BLOB для большинства протоколов, включая OAuth. Вы можете поместить любую нужную вам информацию в любом формате.

Вот что мы делаем,

1. Сначала мы назначаем каждому разработчику ключ с соответствующим секретом.
2. Сам токен представляет собой зашифрованные пары имя-значение. Мы помещаем такие вещи, как имя пользователя, срок действия, идентификатор сессии, роли и т. Д. Он зашифрован нашим собственным секретом, поэтому никто другой не сможет его сделать.
3. Для простоты использования с веб-API мы используем URL-безопасную версию Base64, поэтому токен всегда URL-безопасен.

Надеюсь, это поможет!

Answer 2

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

Вы бы получили рукопожатие, чтобы получить / назначить токен, действительный по времени, на основе вышеуказанного developerKey. Этот токен будет храниться локально и передаваться вызывающей стороне.

Затем разработчик будет использовать этот ключ в запросе для проверки запроса и разработчика.

Например, этот ключ можно использовать в течение 5 минут или для 10 запросов, или как вы определяете. после этого сгенерированный токен времени будет удален из допустимого списка и больше не может использоваться. Разработчик должен будет запросить новый токен.

Answer 3

UUID очень хорошо подходит для любого временного случайного ключа, который вы себе представляете. Непредсказуемо и быстро генерируется, так как столкновения настолько маловероятны, что они фактически уникальны. Сделайте также хорошие сессионные ключи.