нажориста тема оказалась

Человек спрашивал как в универе сессии закрыватт, а мы тут про вебтехнологии...

Ну, @solhov, спрашывающий в чятике как закрывать сэссии в универе — это, как минимум, красиво.

Но спрашивал не я, справедливости ради

Про закрывать сэссии — вроде ты, mrgood вроде чем-то другим интересовался.

А, ну если так

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

Поскольку мы добрались до условия с MITM, добавляем PKCE в стандартный Auth Code Flow, в [скобках] указаны стороны обмена, в угловых инфа, которая есть у <MITM>:

1. Неавторизованный клиент идёт в конечный сервис с простым запросом [клиент - бекенд] <нихрена>.

2. Бекенд сервиса генерит рандомный code, хеширует его (например, sha256 + base64url), генерит ссылку для редиректа на сервис авторизации, в которой передаётся хеш кода (code_challenge), метод хеширования (code_challenge_method) и URL возврата (return_url) редиректит клиента на авторизацию. [бекенд - клиент] <code_challenge, code_challenge_method>.

3. Клиент авторизуется в сервисе авторизации (auth), auth генерит одноразовый auth_code, сохраняет code_challenge и code_challenge_method, редиректит клиента на return_url, в который добавляет auth_code. [auth - клиент] <code_challenge, code_challenge_method, auth_code>

4. Бекенд обрабатывает return_url, получает auth_code, идёт на сервис авторизации за токеном, добавляя в запрос токена code_verifier (сам код, известный только бекенду, который ещё не передавался по сети) [бекенд - auth] <code_challenge, code_challenge_method, auth_code>.

5. Auth обрабатывает запрос, сверяет auth_code, выполняет code_challenge_method для code_verifier, сверяет результат с сохранённым code_challenge, если всё совпало, завершает flow (все коды с этого момента неактивны), отдаёт бекенду JWT access_token [auth - бекенд] <code_challenge, code_challenge_method, auth_code, уже бесполезные>.

6. Бекенд проверяет подпись в токене разворачивает токен, проверяет scope / роли, expire, пофиг что ещё там ему напихали в токен для его специфики, в signed-сессию клиента пишет хоть тупо user_id:1, отдаёт клиенту cookie с этой инфой и дальше полагается уже только на эту локальную инфу, никаких проверок токенов при каждом запросе нет. При желании периодически ходит с refresh_token в auth, узнаёт не отозвана ли там сессия. Или не ходит вообще, а при отзыве сессии ему прилетает коллбек от auth и он инвалидирует сессию у себя.

На всё это при достаточном уровне паранойи можно ещё навернуть привязки к IP, session state и много других весёлых штук, от которых обычно мутнеет голова при реализации.

И всегда остаётся вариант с применением паяльника к клиенту, это тупо дешевле.

Тебе пора статьи писать;)

Ну ты в курсе этого гемора с SSO ))

Браво! 👍

Обратимся только к последнему пункту.
1. Проверок токенов на каждый запрос нет, да. Потому что клиент не использует токены, как ты сказал, у него всё в подписанной куке.
2. На сервисе должна быть реализована база сессий, чтобы сервис мог «по коллбэку инвалидировать сессию клиента». Это ещё раз подтверждает всё, что выше: без общей сущности не получится надёжно реализовать отзыв сессии.
3. При каждом запросе сервер должен не только проверять подпись куки, но и заглядывать в общий стораж сессий, чтобы проверить, валидна ли она ещё. Если не делать это на каждый запрос, то сессию не отозвать мгновенно.
4. У митм есть подписанная кука и он может от имени клиента слать любые запросы

Для пункта 4 есть подпись тела запроса ключем который есть только у клиента :)

2. Ну да, сессии же никто не отменял, мы же говорили про "спиздить токен с клиента"

3. В этом случае это "обычная локальная сессия, как у всех".

4. Денис уже ответил.

Не работает для public http

Ну то есть мы пришли к тому, что «авторизовать клиентов нужно через обычные сессии, хранимые в базе»..? :)

Авторизуйте.

Кончается всё обычной сессией, речь про относительно защищённый способ процесса авторизации.

Защита от Session Hijacking (п.4) - это уже другая история

Всё, больше у меня вопросов нет :)
Я был только против _авторизации_ пользователя по токенам. (Проверка каждого запроса) _Аутентификацию_ по токенам (как описано выше) я и не отрицал, хороший способ :)

Ура! ))

кто всё ещё на http, тот ссзб - народная мудрость