Аутентификация

1) мало времени, но должен быть рефреш-токен для обновления «сессии»

2) нет

3) нет

4) нет

5) нет

Должна быть опция «разлогиниться на всех устрйоствах», при которой убиваются все сессии, кроме той из которой эта команда была вызвана. Либо возможность опционально прибивать сессии по выбору.

Опишите ваши мысли на этот счет плиз.

Кто, блджад, твой клиент и зачем он вообще логинится?

1) мало времени, но должен быть рефреш-токен для обновления «сессии»

Можно подробней идею?

Это не идея, это почти стандарт: после «логина» на сервере (или auth-сервере) клиент получает пару токенов (идентификаторов «сессии»).

access-токен - короткоживущий (минуты), добавляется к каждому сообщению отправляемому клиентом на сервер, по нему и происходит авторизация.

refresh-токен - сравнительно долгоживущий (генерится при процедуре «логина»), по нему сервер возвращает клиенту новый access-токен.

После того как у клиента протух access-токен, он с помощью refresh получает новый и работа продолжается без процедуры «логина», т.е. логин-пароль не требуется.

Преимущество такого подхода - логин-пароль гоняются по сети редко, только для получения пары токенов при логине. Если негодяй угнал access-токен, то воспользоваться он им сможет только в течение нескольких минут.

Недостаток - более сложная реализация мультилогина и некоторые траблы с разлогиниванием.

то что логин и пароль гоняются только в процедуру логина это понятно, для этого и отдается ключ сессии - в вашем примере access токен. но что мешает негодяю угнать и refresh токен раз уж он угнал access токен? какое-то странное уложнение, нет?

что мешает негодяю угнать и refresh токен раз уж он угнал access токен?

А что мешает негодяю получить remote control над устройством с клиентом? А что негодяю мешает угнать логин-пароль? Тогда вообще смысл во всём теряется.

Если исходить из того, что перехват возможен только на этапе запросов-ответов (mitm), то более надежно то, что реже отсылается (рефреш-токен).

Есть вариант, когда auth-сервер отделяется от рабочего, в этом случае логин идет на одном сервере, а на рабочий сервер по потенциально прослушиваемому каналу передается только access.

Есть вариант, когда клиент общается исключительно только с рабочим сервером, а тот в свою очередь транслирует запросы к auth-серверу (вполне себе по приватному каналу), в этом случае рефреш токен не выходит за пределы доверенной зоны и обновлением access-токенов занимается сам сервер.

те речь про какие-то баги https, про недоверие к https как я понимаю.

Нет конечно.

Речь про авторизацию и баланс между удобством клиента и секурностью.

Ты сессии для чего используешь? В том числе и для того чтобы клиент не вводил пароль на каждый чих. Но при этом вероятность, что сессию (токен/куку) угонят. Поэтому клиентская сессия должна быть короткоживущая. Но при этом опять возникает проблема, клиент если у него каждые 5 минут спрашивать логин-пароль, сбежи через полчаса.

Есть варианты интереснее, чем рефреш-токен? Давай, делись.

Пока лично у меня вариантов нет. Гуглю про это. Я как-то не уверен что вероятность того что угонят редко передаваемые данные сквозь какие-то баги https меньше чем часто передаваемые. По идее если баг есть то слушай канал и угоняй. В любом случае спасибо за ответы

Я как-то не уверен что вероятность того что угонят редко передаваемые данные сквозь какие-то баги https меньше чем часто передаваемые.

Повторю вопрос, зачем тебе сессии? ) Гоняй логин-пароль плайн-текстом через https.

1) Клиенту дается в аренду помещение. Как вы считаете сколько должна длиться аренда?
2) Положим клиент купил телевизор, а потом в это же помещение второй. Должен ли клиент избавиться (или иным способом перестать использовать) первый телевизор?
3) Положим клиент купил телевизор, а потом в это же помещение второй. Должен ли он смотреть на обоих телевизорах один и тот же канал?
4) Положим клиент купил телевизор, а потом в это же помещение второй. Положим он выкинул первый телевизор. Должен ли он выкинуть и второй?
5) Положим клиент купил телевизор, а потом в это же помещение второй. Положим он выкинул второй телевизор. Должен ли он выкинуть и первый?
Мыслю я на этот счет что сегодня прямо клиника какая-то на моем ЛОРе...

По сессии не узнаешь логин-пароль перехватили мою сессию, она протухла а пароль не известен. Но это спасет если не будут слушать когда я опять залогинюсь

1) При логине в аккаунт клиенту выдается сессия. Как вы считаете сколько должна жить эта сессия?

Бесконечно, потому что за тухнущие сессии, и, как следствие, необходимость перелогина каждый день/неделю/месяц нужно отрывать руки. Возможно также галка «чужой компьютер» - с ней до закрытия вкладки. Хотя сомневаюсь что этот юзкейс сейчас ещё актуален.

2) Положим клиент залогинился в аккаунт из браузера, а потом в этот же аккаунт из мобильного приложения. Должна ли удалиться при этом сессия созданная для браузера?

Нет.

3) Положим клиент залогинился в аккаунт из браузера, а потом в этот же аккаунт из мобильного приложения. Должна ли для мобильного приложения использоваться та же самая сессия что была создана при логине из браузера?

Нет.

4) Положим клиент залогинился в аккаунт из браузера, а потом в этот же аккаунт из мобильного приложения. Положим я разлогиниваюсь в браузере. Должна ли удалиться при этом сессия созданная для мобильного приложения?

Нет.

5) Положим клиент залогинился в аккаунт из браузера, а потом в этот же аккаунт из мобильного приложения. Положим я разлогиниваюсь мобильном приложении. Должна ли удалиться при этом сессия созданная для браузера?

Нет.

Потому что сессии никак не связаны.

тот же вконтакт точно задавал себе подобные вопросы потому как менял реализацию за время своего существования. вот и у меня уже глаз замылился от долгих лет реализации клиент-серверных систем

Есть варианты интереснее, чем рефреш-токен? Давай, делись.

Звучит как чушь собачья. Если есть возможность что-то угнать, угодят рефреш-токен как угнали бы логин/пароль. Зная рефреш-токен, можно сколько угодно пользоваться угнанным аккаунтом, как и с логином/паролем. Ни крупицы дополнительной безопасности.

Положим клиент купил телевизор, а потом в это же помещение второй. Положим он выкинул первый телевизор. Должен ли он выкинуть и второй?

Положим у клиента украли телефон где он залогинен в сервисе в котором ог регистрировался через почту пароль от которой он не помнит да и пароль от сервиса он тоже не помнит

Зная рефреш-токен, можно сколько угодно пользоваться угнанным аккаунтом, как и с логином/паролем.

Как ты его узнаешь, если им, допустим, рулит сервер?

Ни крупицы дополнительной безопасности.

Оказывается смысл есть - https://m.habrahabr.ru/company/Voximplant/blog/323160/

Спасибо за наводку, буду юзать!

глаз замылился от долгих лет реализации клиент-серверных систем

После вопросов в ОП, страшно подумать, что это за системы, особенно если в них есть авторизация.

И совет, посмотри про JWT.

Что значит «рулит сервер»? Ты даже не понимаешь как это работает. В ссылки на хабр описано неплохо, в целом смысл есть.

в целом смысл есть

Как мы легко переобуваемся. Тьфу на тебя.

И да, мысль, что рефреш-токен необязательно отдавать клиенту слишком тяжела для тебя? Сочувствую.

Я как-то не уверен что вероятность того что угонят редко передаваемые данные сквозь какие-то баги https меньше чем часто передаваемые. По идее если баг есть то слушай канал и угоняй. В любом случае спасибо за ответы

ты как-то немножко дурак. для того, чтобы поиметь однажды угнанный auth token после истечения TTL - тебе надо угнать refresh token. а в большинстве систем, после того, как ты сделал refresh - тебе не продлевается срок действия текущего auth token, а выдается новый, просто без запроса пароля. то есть твой предварительно угнанный auth token можно выбрасывать, толку от него нет. допустим, ты потом угнал новый auth token и попользовался им вместе с уже угнанным refresh токеном - на моменте получения тобой нового auth токена у юзера разлогин и паника, он меняет явки-пароли и привет.

да, если ты психопат-аутист - ты можешь поломать такую схему, но для сервисов, в которых она используется, затраты на взлом будут нихера не соизмеримы с профитом, который можно получить от взлома

Если рефреш токен не отдавать клиенту, он вообще выпадает из контекста обсуждения.

Нет и в той статье на хабре как минимум один юзкейс для этого озвучен.

Про jwt я знаю и про hmac

Оказывается смысл есть - https://m.habrahabr.ru/company/Voximplant/blog/323160/

жесткий misuse темы токенов. хочу напомнить что они stateless...

Никаких «сессий» не существует. «Сессия» это то, что ты сам придумаешь.

сессия должна жить сутки на остальные вопросы «да»