Почему JWT-авторизация использует два раздельных токена (access + refresh), а не один комбинированный?

Question

[Invoidy]

Я предлагаю альтернативную структуру единого токена:

{
  "sub": "#UserId",
  "next_exp": "# Время истечения access-части (короткий срок, ~15 мин)",  
  "last_exp": "# Время истечения refresh-части (долгий срок)"
}

Суть идеи:

При истечении next_exp система проверяет токен в БД и обновляет его (как refresh-токен в классической схеме).

При истечении last_exp пользователь проходит авторизацию заново.

Вопросы:

Почему эта схема не используется, хотя она выглядит проще раздельных access/refresh-токенов?

Стандартный аргумент — «кража только access-токена менее опасна». Но если злоумышленник может перехватить access, почему он не сможет перехватить и refresh? Разделение действительно повышает безопасность?

Есть ли другие недостатки у объединенного подхода, кроме риска компрометации?

Comments

[Сергей Горностаев]

Вы ничего нового не предложили, тот же Keycloak оба токена примерно так и возвращает.

[Invoidy]

Сергей Горностаев, я это понимаю, но почему буквально каждая статья про авторизацию это refresh + access? Вопрос был в этом

[Сергей Горностаев]

Invoidy, потому что нужна возможность делать авторизованные запросы, не трогая БД, но не терять при этом возможность отзыва авторизации.

Answer 1

[Владимир Дубровин]

Понятие access и refresh токена идут не из JWT, а в основном от протокола авторизации OAuth2 (актуальная версия OAuth 2.1), хотя сейчас они используются и за рамками "канонического" OAuth. JWT это просто формат токена, в JWT можно хранить разные виды токенов. Если говорить про access/refresh то в виде JWT рефреши обычно вообще не хранят, иногда хранят access'ы. Но в целом JWT и OAuth2 не связаны. JWT является стандартным способом представления токена в OpenID Connect (OIDC) который основан на OAuth2, там JWT, а точнее JWS или JWE (подписаный и/или зашифрованный JWT) используется для хранения ID Token (не refresh и не access). OIDC это протокол который используют разные ID провайдеры типа Google ID, ЕСИА (Госуслуги), Microsoft, VK ID, Сбер ID и тд и тп

Основная задача OAuth - обеспечить единую точку авторизации в среде со многими сервисами/приложениями и разными типами взаимодействий, в том числе межсервисными, и обеспечить в такой среде изолированные скопы доступа. Рефреш токен долгоживущий и отправляется только центру авторизации, аксесс токен коротко живущий и используется для доступа к конечному сервису (например какому-либо API endpoint'у). При компрометации сервиса (ендпойнта) компрометируется только access token, поэтому после устранения компрометации не требуется сбрасывать сессии.

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

Answer 2

[cython]

Обычно пару токенов хранят в двух разных местах - access в localStorage, refresh в http-only куках. А для получения новой пары требуются оба токена. Безопасность разделения заключается в том, что токены подвержены разным типам атак - access уязвимы для XSS, refresh уязвимы для CSRF, но не оба вместе. Соответственно разделение позволяет предотвратить компрометацию при условии, что не обе атаки реализованы сразу на одного и того же пользователя.

Comments

[Everything_is_bad]

А для получения новой пары требуются оба токена.

уже даже так? как только не извратят идею jwt, используя его там, где не надо. Хотя подозреваю что тут просто кто-то написал полную дичь.

Answer 3

[Everything_is_bad]

В очередной раз когда кто-то пытается доработать jwt, надо показывать это

Comments

[Invoidy]

Я Вас не понимаю, я не пытаюсь придумать что-то новое! Я просто хочу понять как вообще работает JWT авторизация (ее правильная реализация) и почему буквально почти каждый сайт ее использует

[Everything_is_bad]

Invoidy,

почему буквально почти каждый сайт ее использует

не каждый, но достаточное кол-во, по причине - модно молодежно, поэтому jwt суют туда, где от него нет пользы, а только проблемы. Вот для взаимодействия микросервисов и т.п, jwt самое то