Аутентификация на основе сервисов с использованием токенов

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

  • Клиент запрашивает имя пользователя/пароль пользователя
  • Клиент передает имя пользователя/пароль поставщику удостоверений
  • Поставщик проверяет имя пользователя/пароль и отправляет обратно токен, если пользователь действителен.
  • Клиент делает что-то с токеном?

Третий и четвертый шаг - это то место, где я застреваю. Я предполагаю, что "токен" в этом случае просто должен быть либо зашифрованной строкой, которую клиент может расшифровать, либо некоторой случайной строкой, которая хранится где-то (т.е. База данных), которую клиент может проверить, но я не уверен что клиент должен делать с токеном или почему вам даже нужен токен вообще - не может ли быть простой идентификатор пользователя?

ОТВЕТЫ

Ответ 1

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

Нет - токен - это "билет на поездку". Точно так же, как токен метро. Клиент обращается к привратнику при запросе службы. В этом случае поставщик выполняет свою собственную аутентификацию, поэтому клиент представляет токен обратно провайдеру. В некоторых случаях поставщик может делегировать аутентификацию - например, в модель STS, и в этом случае поставщик может передать токен третьей стороне для аутентификации и даже авторизации.

С точки зрения обслуживания этот токен должен:

  • имеют "срок хранения". В противном случае токен будет бесконечно повторно использоваться. Таким образом, на стороне сервера вы можете хранить токен в хранилище на основе сеанса, где вы получите тайм-аут бесплатно. Или вы можете построить простую хеш-таблицу с истечением срока действия.
  • должны быть связаны только с держателем. Во многих случаях поставщик использует приближение здесь и утверждает, что токен может использоваться только с исходного запрашивающего IP-адреса.

Итак, на шаге 3 поставщик должен проверить имя пользователя и пароль. Если это подтвердится, создайте токен (хеш), который ссылается на запись в словаре или Hashtable. Объектами в Hashtable являются структуры, содержащие имя пользователя, IP-адрес, возможно, исходное время выпуска, возможно, роли, связанные с именем пользователя, и все остальное, что вы хотите сохранить. Поставщик услуг отправляет обратно этот токен - хеш, а не структуру - клиенту, обычно как Set-Cookie. Когда клиент отправляет обратно токен (как файл cookie) на последующие запросы, провайдер проверяет словарь, чтобы узнать, доступен ли токен, не был установлен тайм-аут, соответствует запрашивающему IP-адресу, разрешен для запрашиваемого ресурса и т.д. Если все в порядке, почитайте запрос.

EDIT 2013 Июнь

Прошло уже несколько лет, и этот ответ все еще получает голоса. Я бы посоветовал, чтобы люди заглядывали в OAuth 2.0 Framework и маркеры-носители.

В основном они делают именно то, что описано здесь.

Если вы хотите реализовать хороший пример, вы можете посмотреть Apigee Usergrid. Он работает следующим образом:

  • Аутентификация пользователя

    POST https://api.usergrid.com/token -d '{"username":"Joe","password":"Sec4et!","grant_type" : "password"}'

  • Пользователь получает запрос access_token в ответ

  • Пользователь выполняет последующие вызовы с заголовком Authorization: Bearer XXXXXXXXXX, где XXXXX заменяется маркером-носителем. Этот токен имеет время от времени, установленное сервером usergrid.

Ответ 2

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

Ответ 3

Я нашел эту документацию для Amazon S3 полезной, когда искал ту же проблему.

Аутентификация запросов REST

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

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

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

Ответ 4

Это похоже на то, как работает Kerberos.

Ответ 5

Веб-сервис с сеансами... хм-м, не так, как должно быть. Веб-службы не предназначены для сохранения состояния.
Я посмотрел в Интернете, и в большинстве примеров и статьях рассказывается о имени пользователя/пароле SSL/TLS+. Было бы неплохо заменить имя пользователя/пароль инфраструктурой "API-ключ", но я не знаю, как "архитектовать" такую ​​вещь...