Если у автора это просто «метод кодирования», то в чем вопрос «безопасности метода кодирования»?
И причем тут «перехват» (который как раз угроза доставки\хранения)?
Автор явно замахивался на что-то большее чем рассмотрения «метод кодирования». JWT например является частью эко-системы OpenID Connect, который подразумевает что клиент не всегда браузер, а значит надежный cookie management может быть недоступен.
PS: В session-кукисах JWT использовать безусловно можно (вот Play 2 это делает по умолчанию), вопрос целесообразности только.
Непонятный пункт.
Если предположить что клиент это браузер, то зачем вообще JWT, если можно кукисы использовать?
PS: Ни разу не слышал о таком механизме защиты от «перехвата токена» (есть OAuth2.0 Proof-of-Possession, но не похоже что его широко используют в данный момент).
Вы упускаете, что когда Алиса воспользуется тем же рефреш-токеном, который уже использовал Боб — то выданные Бобу токены могут быть инвалидированы сервером (при должных усилиях), об этом косвенно говорит стандарт:
The previous refresh token is invalidated
but retained by the authorization server. If a refresh token is
compromised and subsequently used by both the attacker and the
legitimate client, one of them will present an invalidated refresh
token, which will inform the authorization server of the breach
Например? OAuth2.0/OpenID оно ж только через SSL, так что если только SSL сломают.
а придет она по истечении access-токенов.
Согласен, но ещё зависит как быстро Боб получил Алисины токены. Если вместе с ней, то да — время утечки равно времени жизни access-токена (если других мер не применяется).
Что, как и любое повышение безопасности, будет идти за счет снижения комфорта клиентов.
Иногда репутационные потери гораздо выше потери нескольких не очень аккуратных клиентов. Короче зависит.
Иногда деньги приносит не Алиса, а тот ресурс, к которому Алиса «теряет ключи (токены)».
Если вам на работе выдали ключи, а вы их потеряли — вы просите новые. Так вот если с помощью «потерянных» ключей можно что-то ценное унести, то имеет смысл сменить замки (возможно даже за ваш счет, чтобы бережнее с ключами обходились).
Тут нет однозначного ответа.
токенов допустила именно Алиса
Что неужели сам authorization server?
Уже допустили: как минимум на время жизни access token.
Не совсем верно. Если по факт повторного использования refresh_token-а отзываются все токены выданные ранее этому пользователю, то на время от 0 до жизни access_token — зависит как Алиса придет обновлять токены.
Сервер, несомненно, имеет право. Вопрос в том, будет ли он это делать
Это зависит, от конкретной среды для которой делается сервер. Мое замечание было о
Если в качестве Алисы у вас unattended service, и Боб успешно обменял свой refresh на новый, у Алисы случился отказ в обслуживании, и сколько он продлится — зависит исключительно от того, насколько там подвижные админы. И все это время Боб будет иметь доступ к системе.
Собственно я не согласен с утверждением «всё это время» — не всё, если сервер готов защищаться активно (в том числе от нерасторопных Алис).
А вам не кажется, что фиг с ней с Алисой (раз уж допустила утечку токенов), а гораздо важнее не допустить «учетку данных» к Бобу? И на это в стандарте даже дается намек:
If a refresh token is compromised and subsequently used by both the attacker and the
legitimate client, one of them will present an invalidated refresh
token, which will inform the authorization server of the breach.
Таким образом, если refresh_token использован более 1 раза (Боб обновил, а за ним и Алиса пришла), сервер вполне имеет право отозвать и ранее выданные Бобу токены (access & refresh).
И причем тут «перехват» (который как раз угроза доставки\хранения)?
Автор явно замахивался на что-то большее чем рассмотрения «метод кодирования». JWT например является частью эко-системы OpenID Connect, который подразумевает что клиент не всегда браузер, а значит надежный cookie management может быть недоступен.
PS: В session-кукисах JWT использовать безусловно можно (вот Play 2 это делает по умолчанию), вопрос целесообразности только.
Непонятный пункт.
Если предположить что клиент это браузер, то зачем вообще JWT, если можно кукисы использовать?
PS: Ни разу не слышал о таком механизме защиты от «перехвата токена» (есть OAuth2.0 Proof-of-Possession, но не похоже что его широко используют в данный момент).
Например? OAuth2.0/OpenID оно ж только через SSL, так что если только SSL сломают.
Согласен, но ещё зависит как быстро Боб получил Алисины токены. Если вместе с ней, то да — время утечки равно времени жизни access-токена (если других мер не применяется).
абсолютно согласен.
Иногда репутационные потери гораздо выше потери нескольких не очень аккуратных клиентов. Короче зависит.
Иногда деньги приносит не Алиса, а тот ресурс, к которому Алиса «теряет ключи (токены)».
Если вам на работе выдали ключи, а вы их потеряли — вы просите новые. Так вот если с помощью «потерянных» ключей можно что-то ценное унести, то имеет смысл сменить замки (возможно даже за ваш счет, чтобы бережнее с ключами обходились).
Тут нет однозначного ответа.
Что неужели сам authorization server?
Не совсем верно. Если по факт повторного использования refresh_token-а отзываются все токены выданные ранее этому пользователю, то на время от 0 до жизни access_token — зависит как Алиса придет обновлять токены.
Это зависит, от конкретной среды для которой делается сервер. Мое замечание было о
Собственно я не согласен с утверждением «всё это время» — не всё, если сервер готов защищаться активно (в том числе от нерасторопных Алис).
Таким образом, если refresh_token использован более 1 раза (Боб обновил, а за ним и Алиса пришла), сервер вполне имеет право отозвать и ранее выданные Бобу токены (access & refresh).