Вы предоставляете данные с сервера company1 только в том случае, если был авторизован в company2?
Т.е. вы решаете проблему доступа к данным на сервере account1?
Вы не отвечаете на мой вопрос про консистентность (про смену пароля) =)
Вы при помощи jwt решаете проблему доступа к данным определенного пользователя?
Т.е. если вы запрашиваете статичные данные с company2, то достаточно было бы любой электронной подписи.
Вам jwt по сути нужен только для подписи статичных данных?
То, что сервис может отправлять запросы без аутентификации. К примеру, может ли Some Server запросить данные о пользователе из account.company1 без аутентификации (отдать только id).
Поидее some server использует jwt тольо для получение данных из account.company1.
Может быть вы авторизовываете не то, что надо? Возможно вам нужно аутентифицировать Some Server на account.company1 (К примеру по ip)? Сделать так, чтобы Some Server мог получать инфу из account.company1 по любому пользователю?
Или выдавая jwt вы тем самым выдаете Some Server разрешение на получение данных о пользователе, id которого заложено в jwt?
В данном случае преимущество = нет обращения к бд.
Но если делать access токен со слишком малым временем жизни, то нам необходимо чаще обращаться к бд для валидации refresh.
И все равно остается вопрос о консистентности данных.
Напишите, пожалуйста, как происходит работа?
К примеру:
server1 хранит данные о пользователе и является sso
server2 отвечает за статьи
Пользователь авторизуется на server1 и получает jwt
Пользователь отправляет запрос на server2 с ранее полученным jwt для создания новой статьи.
А насколько малое время жизни должно быть? =)
Из вашего же коммента refresh как правило хранят в бд. Тогда оверхед на использование refresh нивелирует преимущество access token.
Вы говорите про теорию Про теорию написано на той же вики)
А вот юзкейс (именно практика), вот тут я не могу ни найти примера, ни придумать (всё упирается либо в доп валидацию либо в ненужность аутентификации).
Можете привести именно пример использования?
Пользователь заходит на страницу авторизации
Пользователь авторизуется на сервере account.company2
После успешной авторизации происходит редирект на Some Server с пайлоадом в виде jwt
Правильно ли я понял?
Если да, то в случае, к примеру, если пользователь меняет пароль (либо происходит блок пользователя) на сервере account.company2, то доступ к account.company1 все равно сохраняется с предыдущим валидным jwt, так?
А если Some Server доверяет и account.company1 и account.company2, то какой смысл использовать аутентификацию между Some Server и account.company1?
В этом и смысл JWT, что там есть payload.
Но именно юзкейс, где JWT оправдан (не требует доп валидации токена, к примеру отзыв) я не могу ни найти ни придумать.
Можете привести такой пример, где JWT не требует доп валидации и общение сервисов не происходит внутри доверенной сети?
Можете привести юзкейс, где jwt оправдан?
Все случаи, которые я могу представить, либо не требуют аутентификации, либо преимущество jwt нивелируется обращениями к бд.
Можете описать подробнее пример с шапкой? Я не понимаю, что именно вы имеете ввиду. Откуда в данном случае был получен токен.
С микросервисами так же. Откуда они получают запросы? От доверенного источника? Внутри сети?
Проблема именно в том, что токен может быть скомпрометирован. Как вариант — отзывать. Но как проверить отозван ли? Был ли использован refresh token? Или refresh токен можно использовать бесконечно, пока не истечёт?
В чем смысл использовать JWT, если для валидации токена всё равно нужно обращаться в бд?
Внутри закрытой сети авторизация в принципе может не использоваться.
Можете привести юзкейс, где JWT лучший способов аутентификации?
С учётом того, что в мире много всего, чего вы можете не знать, обидеть вас довольно легко =)
А вообще в таких случаях действует простое правило: "Не стыдно не знать, стыдно не учиться". По крайней мере я так говорю своим знакомым и на них это работает =)
Триггер у меня сработал на ваше высказывание про докер, т.к. часто это вижу, и вижу что люди не разбираются в этом. В том, какие трудности были, в том как это работает изнутри.
Если обидел, извини.
Но меня часто выбешивает использование чего-либо в популистическом смысле (когда не разобрался, а говоришь лишь бы украсить высказывание).
Не, у меня 5 час утра
Ну блин, такой интересный рассказ, чем-то похож на мою историю (тоже сайтики, дкп система для клана и т.п.), а в итоге вы в последнем абзаце написали "а как вот так сделать", что больше относится к написанию нового (по-моему мнению), а не "а как это работает", что относилось бы к изучению =)
Всё же я считаю пример с бензопилой не совсем уместным (там травмоопасно =) ). Да и вы сказали, что обучать нужно с азов, а что если некому обучать?) Что если у вас есть желание творить, вы хотите создать тот же сайт, как быстро в вас погаснет искра, если начинаете изучение со структур?)
Лично я начал изучать структуры в школе, на оллимпиадном программировании, но к тому моменту я уже разрабатывал другие программы несколько лет =)
Ладно) мне кажется невозможно дать объективный ответ.
Кстати там пониже мы обсуждаем как раз поверхностные знания и к чему это приводит xD
Насчёт "сь" — запоминающееся событие в школе. Поэтому обратил внимание =)
Но на самом деле это ещё раз иллюстрирует то, что вы не разбираетесь в тонкостях того инструмента, которым пользуетесь =).
А вы знали, что суффикс "сь" указывает на говорящего? =) Т.е. вы извиняете себя =)
Что-то думать (не считать "мелкой" программой) и приводить в качестве аргумента — не одно и то же
Тяжёлый запрос решается кешем.
JWT же про авторизацию
Вы предоставляете данные с сервера company1 только в том случае, если был авторизован в company2?
Т.е. вы решаете проблему доступа к данным на сервере account1?
Сколько у вас живёт токен?
Вы не отвечаете на мой вопрос про консистентность (про смену пароля) =)
Вы при помощи jwt решаете проблему доступа к данным определенного пользователя?
Т.е. если вы запрашиваете статичные данные с company2, то достаточно было бы любой электронной подписи.
Вам jwt по сути нужен только для подписи статичных данных?
То, что сервис может отправлять запросы без аутентификации. К примеру, может ли Some Server запросить данные о пользователе из account.company1 без аутентификации (отдать только id).
Может быть вы авторизовываете не то, что надо? Возможно вам нужно аутентифицировать Some Server на account.company1 (К примеру по ip)? Сделать так, чтобы Some Server мог получать инфу из account.company1 по любому пользователю?
Или выдавая jwt вы тем самым выдаете Some Server разрешение на получение данных о пользователе, id которого заложено в jwt?
Т.е. jwt хранится у Some Server и не передается пользователю?
account.company1 не доверяет Some Server?
А насчет смены пароля пользователя? Или при помощи чего происходит авторизация?
Но если делать access токен со слишком малым временем жизни, то нам необходимо чаще обращаться к бд для валидации refresh.
И все равно остается вопрос о консистентности данных.
К примеру:
server1 хранит данные о пользователе и является sso
server2 отвечает за статьи
Пользователь авторизуется на server1 и получает jwt
Пользователь отправляет запрос на server2 с ранее полученным jwt для создания новой статьи.
Из вашего же коммента refresh как правило хранят в бд. Тогда оверхед на использование refresh нивелирует преимущество access token.
А вот юзкейс (именно практика), вот тут я не могу ни найти примера, ни придумать (всё упирается либо в доп валидацию либо в ненужность аутентификации).
Можете привести именно пример использования?
Пользователь авторизуется на сервере account.company2
После успешной авторизации происходит редирект на Some Server с пайлоадом в виде jwt
Правильно ли я понял?
Если да, то в случае, к примеру, если пользователь меняет пароль (либо происходит блок пользователя) на сервере account.company2, то доступ к account.company1 все равно сохраняется с предыдущим валидным jwt, так?
А если Some Server доверяет и account.company1 и account.company2, то какой смысл использовать аутентификацию между Some Server и account.company1?
Но именно юзкейс, где JWT оправдан (не требует доп валидации токена, к примеру отзыв) я не могу ни найти ни придумать.
Можете привести такой пример, где JWT не требует доп валидации и общение сервисов не происходит внутри доверенной сети?
Можете привести юзкейс, где jwt оправдан?
Все случаи, которые я могу представить, либо не требуют аутентификации, либо преимущество jwt нивелируется обращениями к бд.
Можете описать подробнее пример с шапкой? Я не понимаю, что именно вы имеете ввиду. Откуда в данном случае был получен токен.
С микросервисами так же. Откуда они получают запросы? От доверенного источника? Внутри сети?
Проблема именно в том, что токен может быть скомпрометирован. Как вариант — отзывать. Но как проверить отозван ли? Был ли использован refresh token? Или refresh токен можно использовать бесконечно, пока не истечёт?
В чем смысл использовать JWT, если для валидации токена всё равно нужно обращаться в бд?
Внутри закрытой сети авторизация в принципе может не использоваться.
Можете привести юзкейс, где JWT лучший способов аутентификации?
С учётом того, что в мире много всего, чего вы можете не знать, обидеть вас довольно легко =)
А вообще в таких случаях действует простое правило: "Не стыдно не знать, стыдно не учиться". По крайней мере я так говорю своим знакомым и на них это работает =)
Триггер у меня сработал на ваше высказывание про докер, т.к. часто это вижу, и вижу что люди не разбираются в этом. В том, какие трудности были, в том как это работает изнутри.
Если обидел, извини.
Но меня часто выбешивает использование чего-либо в популистическом смысле (когда не разобрался, а говоришь лишь бы украсить высказывание).
Не, у меня 5 час утра
Ну блин, такой интересный рассказ, чем-то похож на мою историю (тоже сайтики, дкп система для клана и т.п.), а в итоге вы в последнем абзаце написали "а как вот так сделать", что больше относится к написанию нового (по-моему мнению), а не "а как это работает", что относилось бы к изучению =)
Всё же я считаю пример с бензопилой не совсем уместным (там травмоопасно =) ). Да и вы сказали, что обучать нужно с азов, а что если некому обучать?) Что если у вас есть желание творить, вы хотите создать тот же сайт, как быстро в вас погаснет искра, если начинаете изучение со структур?)
Лично я начал изучать структуры в школе, на оллимпиадном программировании, но к тому моменту я уже разрабатывал другие программы несколько лет =)
Ладно) мне кажется невозможно дать объективный ответ.
Кстати там пониже мы обсуждаем как раз поверхностные знания и к чему это приводит xD
Насчёт "сь" — запоминающееся событие в школе. Поэтому обратил внимание =)
Но на самом деле это ещё раз иллюстрирует то, что вы не разбираетесь в тонкостях того инструмента, которым пользуетесь =).
А вы знали, что суффикс "сь" указывает на говорящего? =) Т.е. вы извиняете себя =)
Что-то думать (не считать "мелкой" программой) и приводить в качестве аргумента — не одно и то же