Реализация JWT аутентификации?

Question

[calculator212]

Пробую реализовать аутентификацию JWT и у меня возникло несколько вопросов. Для разлогирования нужно создавать blacklist со списком неавалидных refresh токенов, правильно ли я понимаю что по идее нужно будет еще хранить и список отозванных access токенов, пока она валидны, т.к. чтобы обеспечить мгновенный выход на всех устройствах, то нужно будет запретить доступ и по ним? Правильно ли я рассуждаю или нет?

Answer 1

[Илья]

Вы только что придумали reference token. Лучше сразу реализовывайте его. Потому что в реализации которую вы указали jwt скорее вреден, чем полезен.

Comments

[calculator212]

Илья, спасибо за ответ, я дальше буду разбираться с темой, но хотел уточнить, reference token реализуется в Oauth 2.0 например? И я тогда вообще не понимаю зачем тогда использовать JWT, если для сайта на одном домене есть куки, а для аутентификации на нескольких доменах есть Oauth 2, просто я тогда совсем не понимаю смысл системы аутентификации, которая не позволяет сразу выйти из всех сессий в приложении. Я видел статьи, что подход с blacklist в целом не дает преимущество над куками.
два плюса, которые я нашел jwt можно передавать между разными доменами и если нужно мобильное приложение, то лучше его использовать.

[Илья]

И я тогда вообще не понимаю зачем тогда использовать JWT, если для сайта на одном домене есть куки, а для аутентификации на нескольких доменах есть Oauth 2

А это типичная проблема, потому что OAuth2.0 был придуман не для того, что вы от него хотите.
Если читать RFC:

The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf.

То есть это штука которая позволяет сторонним приложениям получать ограниченный доступ к вашему приложению. В самой спецификации нет упоминания jwt, это одна из реализаций. Причем реализация такая что jwt токен является самодостаточным и для его проверки не требуется повторно обращаться к серверу авторизации. Это означает что отзыв такого такого токена не подразумевается в принципе. Это вполне рабочая ситуация когда вы можете позволить себе выдавать короткоживущие токены (на 1 час или на 15 минут или на 5 минут) и у вас нет требования по мгновенному разлогину.
Если есть требования по мгновенному разлогину, то нужно сразу использовать reference token, и каждый раз проверять токен через сервер авторизации.

[Илья]

calculator212, у вас свой сервер авторизации или вы используете кого-то как постащика пользовательских данных?

[calculator212]

Илья,

у вас свой сервер авторизации или

сервер свой.

[Илья]

calculator212,
https://identityserver4.readthedocs.io/en/latest/
Вот рекомендую посмотреть этот проект. В нем реализован и jwt и refresh_token и еще много чего вроде OpenIdConnect. Язык программирования может и не совпадет с вашим, но сами концепции полезно будет глянуть.

[calculator212]

Илья, спасибо. Я правильно понимаю, что такую аутентификацию можно будет и в проде использовать?

[Илья]

calculator212, если вы про identityserver, то да. У меня есть несколько проектов где он используется в проде. И microsoft одобряет этот проект https://docs.microsoft.com/en-us/dotnet/architectu...

[calculator212]

Илья, спасибо буду разбираться.