Search
Write a publication
Pull to refresh
10
0
Таир Сабыргалиев @tsabir

User

Send message

Чтобы этих лучших спецов не получили конкуренты

Иногда нужно запустить команду с определенными переменными окружения, можно сделать это одной строкой:
$ JAVA_HOME=/java/home ./run.sh

Ну что тут сказать… Отличный цугцванг со стороны этой самой Zhubai Seine Group

«Изначально полицейские получили информацию о том, что в этом доме работает нелегальный колл-центр» — наверное ОПСОС тупо пожаловался после бешеной нагрузки на базовую станцию

В целом я согласен, что через редирект безопаснее, но все же:


  1. есть Apple Keychain и его аналоги на других платформах
  2. не понял. HTTPS же обычно есть

Ну вот, я это и имел ввиду. Если Аксесс-токен обновлять строго через редирект, то на клиенте не будет храниться ничего, поэтому нет смысла его защищать

Ну я в какой-то момент так предположил, но теперь что-то засомневался.


в случае без рефреш-токена, как этот вопрос решается?

Тут я согласен, редирект однозначно это решает.

Я если честно, вижу только 1 неприятный момент — это утечка Рефреш-токена. Остальное абстрагируется же библиотекой?

Если честно, я зашел в тупик.


я пишу


Думаю, в случае с RefreshToken предлагается более универсальный подход, нежели всякие Session Cookie и редиректы в браузерах

вы отвечаете:


Не универсальный
Весь смысл включения рефреш токена — доступ к ресурсу. когда пользователь не имеет активной сессии.

То есть, если есть сессия, то пользоваться Рефреш-токеном для получения Аксес-токена — моветон? Зачем мне реализовывать в клиенте 2 способа, когда у меня есть Рефреш?

Я не могу никак понять, зачем вы все приплетаете сессии и браузеры? OAuth и OpenID Connect не ограничен ими.

А если нет возможности implicit flow? Почему вы прицепились к браузеру?

Вот именно, что универсальный, так как не привязан вообще к сессиям и браузерам

имеющий свои ограничения

Имеете ввиду какие-то технические ограничения? Можно примеры?

А где в OAuth 2.0 написано про легаси?


Как по мне, так авторизация в браузере как раз есть частный случай такого гранта, а resource owner просто доверяет ему хранение паролей и куков.


Также некоторые AS позволяют без браузера при этом защищают через MFA например ну или через всякие Apple Social.


Я понимаю, что вы имеете ввиду всякие Фэйсбуки и Твиттеры и их политики, но OAuth не только под них же писан в конце-концов.

Нельзя сделать OAuth без "редиректов в браузерах" (либо вам придется заставлять пользователя вводить информацию руками).

Странный аргумент. Хотите сказать, что Resource Owner Password Credentials Grant уже не является частью OAuth?

Нет, технически я переложил ответственность за долгосрочную сессию с клиента на AS. Сам клиент в этом случае становится существенно проще.

Позвольте не согласиться, вы переложили ответственность на веб-браузер.


Ну и, далеко не все клиенты в браузере.
Я и не говорил, что этот подход всегда работает.

Думаю, в случае с RefreshToken предлагается более универсальный подход, нежели всякие Session Cookie и редиректы в браузерах

Ну я бы не сказал, что этот способ прямо разительно отличается. Технически, вы просто заменили RefreshToken на Session cookie. Ну и, далеко не все клиенты в браузере.

есть больше одного сценария, когда без рефреша прекрасно обходятся

не совсем понял, без рефреша как-то продлевают сессию?

Information

Rating
Does not participate
Location
Астана, Акмолинская обл. (Целиноградская обл.), Казахстан
Date of birth
Registered
Activity