Да при чем тут implementor's guide?
Issuer, Audience и подобные поля имеют смысл, если в них есть что писать :)
Если у вас только 1 issuer и все токены только для одного Audience («все пользователи»), что толку заполнять эти поля?
Чем они повысят безопасность?
Да да? :)
А если я сам пишу AS, RS и клиент (вы же мне этого не запретите?)
И плевать хотел на все issuer и audience (допустим у меня их «по одному»).
Что выходит мне JWT запрещено использовать? :)
Ну да, тому откуда приложение в браузер загружается.
Если все части распределенной OAuth2 системы скомпрометированы (включая AS и клиент), то тут уже «поздно пить Боржоми».
Но TLS сертификат к механизму подписи JWT отношения не имеет.
Первая загрузка клиентского приложения (например SPA в браузер) все же не в счет. Этого обращения к серверу, как и первого логина с паролем, не избежать.
Ну… не совсем.
Яваскрипт-то не обязательно идет с AS, он идет с Resource Server'a.
В случае смены private/public key пары да, придется две стороны обновлять.
Но клиент все равно не затронут :)
Хотя, возможно, подробности зависят от конкретного OAuth2 flow.
Не, ну да.
Но кстати если «хардкодить public key в яваскрипт», то при потере и последующей смене private key клиенты мало что заметят, потому что будут скачивать и использовать новый/обновленный public key.
эти поля опциональные и как бы «резервируются» для реализаций, в случае если они вдруг им понадобятся. Обязательный набор JWT полей для минимальной реализации совсем небольшой.
Ну обычно да.
Resource Server обращается при каждом клиентском запросе к authorization server, чтобы убедиться, что все ок.
Но
Если вдруг authorization server недоступен (как например в сценарии SSO между двумя независимыми системами), то обращаться за проверкой некуда (например нету сетевой связи с AS, выдавшим токен).
Тут его подлинность можно проверить только с помощью криптографической подписи токена.
Почему это сертификат?
Ассиметричное шифрование предполагает использование пары public и private ключей.
Подпиши токен private ключем и раздай private key всем пользователям, кто об этом попросит, свой public key и вот они уже могут счастливо проверять подлинность JWT токенов без лишних раундтрипов к тебе же.
(я такое делал, и именно с JWT токенами, все работает)
Пользовательскую сессию не обязательно реализовывать в виде HTTP сессии.
Если делать сервисы stateless и не хранить ничего пользовательского в памяти, вполне можно обойтись OAuth2 токенами для определения когда сессия, определенная ими, истекла: как только authorization server отказывается аутентифицировать access и/или refresh token переправляем пользователя на Login screen.
Issuer, Audience и подобные поля имеют смысл, если в них есть что писать :)
Если у вас только 1 issuer и все токены только для одного Audience («все пользователи»), что толку заполнять эти поля?
Чем они повысят безопасность?
Хочу — реализую, хочу — беру готовое решение.
А если я сам пишу AS, RS и клиент (вы же мне этого не запретите?)
И плевать хотел на все issuer и audience (допустим у меня их «по одному»).
Что выходит мне JWT запрещено использовать? :)
Если все части распределенной OAuth2 системы скомпрометированы (включая AS и клиент), то тут уже «поздно пить Боржоми».
Но TLS сертификат к механизму подписи JWT отношения не имеет.
Яваскрипт-то не обязательно идет с AS, он идет с Resource Server'a.
В случае смены private/public key пары да, придется две стороны обновлять.
Но клиент все равно не затронут :)
Хотя, возможно, подробности зависят от конкретного OAuth2 flow.
Но кстати если «хардкодить public key в яваскрипт», то при потере и последующей смене private key клиенты мало что заметят, потому что будут скачивать и использовать новый/обновленный public key.
Зайдите на jwt.io и проверяйте токены, используя любые пары ключей.
Если доверяешь домену, с которого скачиваешь его, то этого должно быть досточно.
Resource Server обращается при каждом клиентском запросе к authorization server, чтобы убедиться, что все ок.
Но
Если вдруг authorization server недоступен (как например в сценарии SSO между двумя независимыми системами), то обращаться за проверкой некуда (например нету сетевой связи с AS, выдавшим токен).
Тут его подлинность можно проверить только с помощью криптографической подписи токена.
Ассиметричное шифрование предполагает использование пары public и private ключей.
Подпиши токен private ключем и раздай private key всем пользователям, кто об этом попросит, свой public key и вот они уже могут счастливо проверять подлинность JWT токенов без лишних раундтрипов к тебе же.
(я такое делал, и именно с JWT токенами, все работает)
Если делать сервисы stateless и не хранить ничего пользовательского в памяти, вполне можно обойтись OAuth2 токенами для определения когда сессия, определенная ими, истекла: как только authorization server отказывается аутентифицировать access и/или refresh token переправляем пользователя на Login screen.