Комментарии 6
>Как выглядит JWT и как он зашивает с себе всю информацию? Это три закодированные последовательности символов, записанные через точку: в первых двух частях в base64 кодируются два JSON-объекта — заголовок и пользовательские данные; третья генерируется на основе первых двух и секретного ключа — это цифровая подпись. Теперь сам токен в открытом виде содержит всю необходимую информацию для авторизации, а цифровая подпись не позволяет что-то в токене поменять. Когда система принимает запрос, она знает секретный ключ и может сама сгенерировать подпись и проверить, совпадает ли она с тем, что нам передали.
Кодировка на самом деле base64url. Данные могут быть и зашированы, и это реально делают сервисы например google auth2. Для подписи чаще испрользуют криптографию с закрытым и открытым ключом. И как раз для проверки подписи достатоно открытого ключа.
>При этом старый refresh заносится в черный список и больше не может быть использован. Обращаться к внешнему хранилищу все-таки надо, но уже не так часто.
Надо четко представлять, что все что связано с refresh token и методы ротации токенов не оределены в стандарте и относятся к категории городского фольклора. Единствекнный смысл ао времени жизни токенов следующий
1) время жизни access токена является периодом для которого в данном конкретном приложении допустимо не перзарашивать данные о пользователе в системе. При этом возникает иногда необзодимостьнемедленного отзыва access токено для чего формируют черный список
2) время жизни refresh токена это собственно время после которого произойдет разлогин клиента если не было активности клиента
Что касается одноразовости refresh токена - в реальном приложении это может привести к багам так как два и более одновременно выполняющихся хароса могут потребовать смены токена при этом только один из них будет успешным. Профит от одноразовости токена весьма сомнительный.
Насколько я все хорошо понял, для подавляющего большинства сервисов даже рассуждать о реализации подобных механизмов с нуля, даже с использованием готовых библиотек, для продакшена — дело крайне неблагодарное, очень легко ошибиться, рискнуть всем и не получить вообще ничего.
Я работаю со стеком js у на с б блиотеками с популярными все нормально. Реализации адекватные наверное на python тоже есть такие если не попасть случайно на экзотику. Тут скорее речь идёт о том что непонимание того что может и что не может токен приводит к решениям которые выглядят просто неубедительно. Например хранение товаров в базе данных. Или хранение в товаре тол ко идентификатора пользователя. Или вообще идентификатора сессии. Одноразовое использование токена принадлежит к той же серии. Несмотря на повсеместное распрос ранение этой традиции я так и не услышал ни одного убедительного объяснения зачем это нужно. Говорят что так безопасно. Но в чем эта безопасность заключается я так и не понял. Если злоумышленник получил токен точное ему мешает тут же им и воспользоваться?
Вцелом jwt можно рекомендовать к испол доверию во все проектах без исключения. Только сначала нужно просто подумать
Очень хочу попросить автора: пожалуйста, никогда не пишите код в виде исходных файлов для diff.
Вот мне нужно очень быстро сделать аутенфикацию через сессию. Я перехожу в этот раздел и вижу... вместо кода и объяснение какие-то строки, помеченные плюсами и минусами. То есть чтобы сделать аутенфикацию через JWT, я должен буду сначала сделать её на Basic, потом переделать на Token, потом уже её передалать на JWT.
Спасибо, я пойду искать другую статью. В которой можно хоть что-то понять, кроме плюсиков и минусиков.
Спасибо за комментарий и обратную связь
Материал подготавливался под сильным влиянием предполжения, что он будет прочитан от корки до корки - согласен, что это слишком жесткое ограничение и отсеивает значительный пласт аудитории, у которых потребности вроде ваших
И я тогда не знал, как добиться наглядности... И да, додумался до вот этого:)
Как серверу на Django знать своих клиентов на React в лицо, практическое руководство