или даже щас чуть проще сделаю

во https://play.golang.org/p/FTlVG6mchb4

Hi
What is the best way to use JWT token in go (gin framework)?
I tried this method but I did not like it

https://learn.vonage.com/blog/2020/03/13/using-jwt-for-authentication-in-a-golang-application-dr/#

I don't see where is validation part here, in article you've linked. I guess there should be around ready to use gin middlewares which make use JWT for access control. However, issuing token in article is more or less correct and there won't be much of improvement on this. Also, speaking of article you linked, I don't see point using Redis here. It kind of defies benefits of use of stateless JWT tokens.

If you care about token validity and revocations - just use plain sessions

That's right
I added radis myself
Is there no suitable package to do these things automatically?

А что вы используете для механизма аутентификации? Звучит так, будто бы jwt практически не пригоден. При смене пароля, никак не отозвать токены, если не сохранять их, соответственно выйти со всех устройств нельзя. Быстрые изменения ролей без ожидания истечения жизни токена тоже с токеном не сделать. Ну то есть в клеймсы нельзя права положить. Можно хранить в редисе роли с айдишником юзера в качестве ключа. Ну и только айдишник юзера в токене хранить.

если вам нужен мгновенный логаут и/или логаут со всех устройств - jwt не годится, и тут мы начинаем хранить сессии

ну да, сессии.. Я вообще ожидал услышать IdentityServer. Сам им никогда не пользовался, думаю посмотреть

обычно аутентификацию уносят в отдельный сервис, да

айдентити сервер у того же payaware работает с jwt-токенами

и да, используется для аутентификации пользователей

сессии хорошо, но только подписанные токены сервис-провайдер может завалидировать самостоятельно без участия айдентити-провайдера

свои ограничения, конечно, есть

есть два подхода:
1. хранить в условном профиле пользователя атрибут - минимальную дату выпуска токена. при обновлении пароля обновлять эту дату.
2. отзывать токены по jti. список отозванных jti всё же меньше, чем все сессии со всеми их данными

И список меньше и требования к его доступности, надёжности ниже. Будем честны.

Чего это?

Все равно каждый запрос проверять по этой базе.

А проверку по уникальному индексу все равно, по тысяче или по миллиону делать

в плане размещения в памяти размер имеет всё-таки значение

насчёт доступности - у нас есть похожий пример для сравнения

и какое же?

давайте прикинем в байтах