Схема аутентификации веб-API

Я реализую оставшийся API для использования новой среды веб-API. Этот API будет использоваться другими компаниями, поэтому мы добавим метод аутентификации.

Что касается аутентификации, я думаю реализовать что-то на основе токенов. Что-то вроде этого

  • клиент предоставляет учетные данные для входа в систему
  • система аутентифицирует клиента и отправляет токен
  • клиент использует этот токен при следующих вызовах API

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

Как бы вы рекомендовали реализовать схему аутентификации для этого сценария?


authentication asp.net asp.net-web-api
person StackOverflower    schedule 09.08.2012    source источник
comment
Взгляните на это, используя аутентификацию HMAC: веб-API создание ключей API"> stackoverflow.com/questions/11830338/   -  person cuongle    schedule 09.08.2012

Ответы (2)


arrow_upward
1
arrow_downward

Создать подобную схему аутентификации на основе токенов непросто.

У меня действительно нет ответа, как вы могли бы реализовать это хорошим и безопасным способом. Но предложу некоторые мысли, которые приходят мне в голову, о проблемах, с которыми вам придется иметь дело:

  • Генерация токенов должна быть хорошо рандомизирована, а токены должны быть «достаточно» (для некоторого определения достаточно) длинными, чтобы кто-то не мог просто отправить кучу разных токенов, чтобы увидеть, «получит ли он хит»

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

  • Как вы можете надежно убедиться, что токен не был «похищен».

Если токен представляет собой просто какую-то случайную строку, то любой, кто случайно «увидит» его при передаче (использует SSL), сможет предположить идентичность использования, для которого был сгенерирован токен.

Токен, полученный вашей службой, сообщит вам, что:

  • Ваше приложение выдало токен пользователю/приложению/сущности X
  • Токен цел (не менялся)
  • Любая другая вещь, которую вы храните с токеном (срок его действия и т. д.)

Но без дополнительных усилий он не даст вам знать наверняка, что он был отправлен пользователем/приложением/объектом X. Может быть Y, которому удалось завладеть токеном.

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

person user1429080    schedule 09.08.2012
comment
Как насчет использования существующего генератора токенов, такого как проверка подлинности с помощью форм ASP.NET? - person Snixtor; 26.11.2012

arrow_upward
2
arrow_downward

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

Это обеспечит передачу информации для входа только после истечения срока действия токена, а при создании нового токена будет удалена старая запись токена.

Я правильно понимаю ваши требования?

person Jeff Turner    schedule 09.08.2012