Как я уже писал выше, JWT — это формат. К OAuth2 протоколу прямого отношения не имеет. Используется чаще для установления SSO между независимыми системами (из-за своей способности нести в себе дополнительную информацию).
Теперь возвращаемся «к нашим баранам».
Итак, как верификация в вашем примере (того что JWT токен не поддельный) поможет без обращения к системе, которая его выдала, проверить отозван токен или нет?
Тут какое-то явное противоречие.
С одной стороны мы поддерживаем revocation access token'a, а с другой не обращаемся к authorization server'у и БД чтобы проверить, а не «отозван» ли наш токен :-/
А как проверять правильный ли переданный access token, если не хранить его в БД Authorization Server'a?
Можно конечно держать их в памяти и сравнивать, но тогда ваш Authorization Server перестает быть stateless, скалируется плохо, начинает требовать репликации данных в памяти между инстансами, возможно sticky-sessions на load balancer'e и все это только потому что мы решили не хранить его в БД.
Смысл refresh token'a как раз в том, что с ним для получения access token'a не нужен пароль.
Если есть валидный refresh token, то пользователь в UI ничего не заметит когда его access token истечет и просто незаметно продолжит работу дальше, и так 8 часов.
Если бы у пользователя/клиента не было бы валидного refresh token'a, то единственным способом получить/обновить access token для продолжения работы была бы аутентификация «с самого начала», т.е. предъявления своего секрета (пароля). В этом случае, очевидно, пришлось бы вводить пароль каждые 15 минут.
Если «украли/утек» refresh токен — то конечно беда на следующие 8 часов, лучше его бережно хранить на клиенте. Но зато он хоть путешествует по сети редко (раз в 15 минут, а не при каждом запросе сервера), так что перехватить его труднее (а по SSL и того сложнее).
Извините, но это (e.g. «использовать его для своей сессии») все больше напоминает какую-то демагогию.
Предлагаю разобраться самостоятельно в спокойной обстановке.
Я скорее не соглашусь.
Но смотря как вы определяете пользовательскую сессию.
Если пользовательськая сессия — это время валидности access token'а, то да.
Иначе — нет.
Вы мешаете кучу терминов в одну кучу… Очень долго раскручивать.
JWT — это формат носителя SSO token'a
К OAuth2 и refresh token'у это [прямого] отношения не имеет.
Повторяю еще раз, мое утверждение валидно для OAuth2.
Я не утверждал и не собираюсь доказывать, что оно валидно для SSO.
Refresh Token — часть OAuth2 протокола.
Моя проблема не имеет ничего общего с SSO.
В ней речь идет об аутентификации в пределах одной системы, а не Single Sign On в несколько разных независимых.
«обычно» :)
Повторюсь, OAuth2/OpenID Connect и SSO (который на чем душа пожелает можно реализовывать, хоть SAML2, хоть JWT) — две совершенно разные вещи
1) Access token валиден 15 минут
2) Через 15 минут клиент получает «отлуп» при попытке выполнить очередную операцию.
3) Вместо того чтобы снова спрашивать пользователя ввести пароль, клиент отправляет refresh token для аутентификации.
4) Refresh token валиден 8 часов
5) Повторять шаги 2-4 8 часов подряд
6) Через 8 часов попытка аутентификации с помощью refresh токена закончится неудачей и тогда уже можно спрашивать пароль по-новой
http://tutorials.jenkov.com/oauth2/roles.html
Теперь возвращаемся «к нашим баранам».
Итак, как верификация в вашем примере (того что JWT токен не поддельный) поможет без обращения к системе, которая его выдала, проверить отозван токен или нет?
Я это и имею в виду.
в базе данных чего?
С одной стороны мы поддерживаем revocation access token'a, а с другой не обращаемся к authorization server'у и БД чтобы проверить, а не «отозван» ли наш токен :-/
Можно конечно держать их в памяти и сравнивать, но тогда ваш Authorization Server перестает быть stateless, скалируется плохо, начинает требовать репликации данных в памяти между инстансами, возможно sticky-sessions на load balancer'e и все это только потому что мы решили не хранить его в БД.
Если есть валидный refresh token, то пользователь в UI ничего не заметит когда его access token истечет и просто незаметно продолжит работу дальше, и так 8 часов.
Если бы у пользователя/клиента не было бы валидного refresh token'a, то единственным способом получить/обновить access token для продолжения работы была бы аутентификация «с самого начала», т.е. предъявления своего секрета (пароля). В этом случае, очевидно, пришлось бы вводить пароль каждые 15 минут.
Если «украли/утек» refresh токен — то конечно беда на следующие 8 часов, лучше его бережно хранить на клиенте. Но зато он хоть путешествует по сети редко (раз в 15 минут, а не при каждом запросе сервера), так что перехватить его труднее (а по SSL и того сложнее).
https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/
Предлагаю разобраться самостоятельно в спокойной обстановке.
Но смотря как вы определяете пользовательскую сессию.
Если пользовательськая сессия — это время валидности access token'а, то да.
Иначе — нет.
JWT — это формат носителя SSO token'a
К OAuth2 и refresh token'у это [прямого] отношения не имеет.
Повторяю еще раз, мое утверждение валидно для OAuth2.
Я не утверждал и не собираюсь доказывать, что оно валидно для SSO.
2) Так я о том же, SSO тут ни при чем, уберите его из своих комментариев и мы с вами быстро согласимся :)
Моя проблема не имеет ничего общего с SSO.
В ней речь идет об аутентификации в пределах одной системы, а не Single Sign On в несколько разных независимых.
Повторюсь, OAuth2/OpenID Connect и SSO (который на чем душа пожелает можно реализовывать, хоть SAML2, хоть JWT) — две совершенно разные вещи
2) Через 15 минут клиент получает «отлуп» при попытке выполнить очередную операцию.
3) Вместо того чтобы снова спрашивать пользователя ввести пароль, клиент отправляет refresh token для аутентификации.
4) Refresh token валиден 8 часов
5) Повторять шаги 2-4 8 часов подряд
6) Через 8 часов попытка аутентификации с помощью refresh токена закончится неудачей и тогда уже можно спрашивать пароль по-новой