Исправление
kostyarin_,
(текущая версия)
:
Не всегда есть смысл хранить все данные из токена в СУБД. Или например, если есть интеграция со сторонней системой, то нужно туда передать какие-либо данные (тот же UUID пользователя). Или в какой-нибудь платёжной системе, надо сгенерировать токен, который может пройти через 3-4 посредников до того, как доберётся до пользователя, но заказчик смог бы из токена достать ID ордера, при этом быть уверенным, что подмены не было.
В этом случае один и тот же токен используется и для авторизации и для подписи. Если одельно – то это просто подпись, типа HMAC. И что? На авторизацию это никак не влияет. Если отдельно – то это отдельная тема. Т.к. здесь он используется только как типа HMAC. Но при чём тут тогда отзыв и всё такое. Те 3-4 посредника никак не узнают про всё это, про бан и понижение в правах. Всё что они могут знать – достоверны ли данные в токене.
P.S. может быть выгодно использовать JWT вместо session key – если но используется и для авторизации и для чего-то ещё – я согласен.
Исходная версия
kostyarin_,
:
Не всегда есть смысл хранить все данные из токена в СУБД. Или например, если есть интеграция со сторонней системой, то нужно туда передать какие-либо данные (тот же UUID пользователя). Или в какой-нибудь платёжной системе, надо сгенерировать токен, который может пройти через 3-4 посредников до того, как доберётся до пользователя, но заказчик смог бы из токена достать ID ордера, при этом быть уверенным, что подмены не было.
В этом случае один и тот же токен используется и для авторизации и для подписи. Если одельно – то это просто подпись, типа HMAC. И что? На авторизацию это никак не влияет. Если отдельно – то это отдельная тема. Т.к. здесь он используется только как типа HMAC. Но при чём тут тогда отзыв и всё такое. Те 3-4 посредника никак не узнают про всё это, про бан и понижение в правах. Всё что они могут знать – достоверны ли данные в токене.