Ответ 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.