Агнец за бортомСессии в памяти - это же мета -нубство. Например, на той же node.js есть чудесный менеджер процессов PM2, который с минимумом усилий запускает процессы ноды на произвольном количестве ядер.

Это на ровном месте прилично бустит производительность. Но это тут же обуславливает невозможность хранения сессии в памяти.

Ну и фиг с ними. Нужно будет что-то в кеш для пользователя засунуть, так, чтобы всем нодам это было видно, заюзаю распределённый кеш, но лучше всегда всё делать stateless. :)

Агнец за бортомВообще не соображают, о чем пишут.

Согласен, дока в сети в основном не айс. Но к тому времени, когда где-то собирается айс, прогресс уже уехал :)

Агнец за бортомА почему в токене есть инфа только

потому что время на сервере SSO может отличаться от времени клиента

Агнец за бортомИ еще - idP, который возвращает мне (.NET) JSON-токен с маркерами - разве не должен прислать мне их с зашифрованными с секретом?

каким ещё секретом? nonce?

Агнец за бортомСправедливо. То есть - самому писать в тот же токен?

да, если хочешь :) но смысла особого нет.

Агнец за бортомНу, смысл JWT-токена, что он шифруется секретом, который знают только две стороны. (.net и idP).
А он мне его прислал вообще в открытом виде.

токен не шифруется, он подписывается, важна достоверность, чтобы не подделали. а шифровать ничего не нужно, так как передаётся всё по https, зачем эти ненужные телодвижения?

Агнец за бортом,

вот можешь поиграться

https://jwt.io/

видишь, 3 часть токена это подпись? это всё. больше никакого шифрования.

Агнец за бортомНу ок, но почему idP мне все эти токены шлёт в открытую, JSON-ом?

Это нормально?

Да, нормально.

Смотри. Допустим, у тебя есть твой сервер A, клиент K и сервер авторизации S.

В случае толстого клиента, К может авторизоваться на S самостоятельно, получить токен и дальнейшие обращения делать на сервер А с полученным токеном. При этом за обновление и сопровождение токена клиент сам отвечает. Он только предъявляет его серверу А, смотри, мне разрешено.

Что бы мог сделать сервер А. Он мог бы, получив токен, сделать запрос на S, чтобы удостовериться, может быть это какая-то лажа. Но ему это делать не нужно, он просто может проверить подпись. Для создания подписи участвует секретный ключ, известный серверу приложений А и серверу авторизации S. Клиент его не знает, значит не может подделать токен.

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

Petro123Например, SAML шифруется.

Да нафиг он нужон, сложный и деревянный :)

Агнец за бортом,

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

В основном SSO отвечает за аутентификацию, и за авторизацию в приложении. Набор полномочий, с которыми он авторизуется в приложении сохраняется в токен, если он вариативный. Т.е. им управляет сам пользователь при входе. Допустим, SSO спрашивает, вы хотите предоставить приложению доступ к вашему телефону? Месту расположения? Как кто вы хотите войти (функциональная роль)? И т.п.

Если это не нужно, достаточно того, что токен содержит в payload username/userid/givenname.

Агнец за бортомНо тогда всю движуху по подписыванию токена - надо брать на себя?

Нет, зачем? Существующие библиотеки это делают с любым объёмом атрибутов токена.

Но большой токен это не гуд.


Агнец за бортомЗачем он подписывает "идентификационный маркер", а два других - как есть?

JWT состоит из 3-х частей:

1. хедер
2. нагрузка (полезные данные)
3. подпись

подпись это хеш от 1+2+secret key

Агнец за бортомЕсли мы говорим о stateless, то надо запихивать в токен кучу дополнительной инфы и подписывать её самому.

подписывается хедер и нагрузка, чего бы ты в нагрузку не напихал. одинаково при любом объёме.

Агнец за бортомВопрос - можно ли сделать так, чтобы содержание (то есть - сами значения атрибутов) сразу записывались в payload после аутентификации?? Чтобы не было нужды в дополнительном запросе.

Конечно, записывай их в payload на стороне SSO, только смотри, чтобы токен сильно не распух.


Агнец за бортомP.S. OAUTH2 считается намного проще, чем OAUTH без номера. Страшно представить - что там было.

oauth это только access token по сути, проще это типа сами думайте что с этим дальше делать. и придумали, появился openid connect ))

Агнец за бортомhVosttКонечно, записывай их в payload на стороне SSO,

Я как-то этим там не рулю..

Это зависит от реализации сервера?

Ты чего используешь для SSO всё-таки?