Все описано, кроме самого главного: где client-ам эти гребанные токены хранить (особенно рефреш). Это к слову об упрощении для разработчиков :)

Зависит от проекта, например простите куки :)

А рефреш-токен? RP не должен его получать :)

Ну ещё раз, зависит от Вы хотите получить совета из абстрактной архитектуры :)

Читайте изучайте

Я просто хочу best practice, которые применимые в реальной жизни, а не космические корабли, бороздящие просторы, которые ещё нужно умудриться натянуть на глобус.

Хех В современном мире про это можно забыть. Практика проекта одного проекта, может не подходить под другой Как по мне нет серебренной пули

Читал-изучал. И только утвердился в мнении, что разработчику в соответствии с рекомендациями внедрить oidc без костылей нельзя.
Впрочем, ничего лучше oidc, к сожалению, всё равно нет.

Ну и это да

С oidc проблема в том, что читаешь rfc, и понимаешь, что на банальную задачу "сервису нужно аутентифицировать своих пользователей" эти требования не ложаться никак. Потому что сервис является и client-ом, и RP одновременно.

Можно почитать rfc почты и если ему следовать, то ничего работать не будет :)

Увы мир такой какой он есть

а в базенке нельзя, ну там для кеша которая например. Правда каждому сервису по in memory наверное дичь

а напомни кто такой RP в oidc?

Relying party

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

пошёл гуглить "имперсонировать" =)

а разве ресурс сервер, не возвращает его вместе с access токеном?

Привет!
Подскажите, пожалуйста, по postfix .
У меня как relay клиент он используется для почты office365.
Где throttling, 30 сообщении в минуту. В настоящий момент, хочу добиться отправки писем,
29 сообщении в минуту. Иначе днем очереди скапливаются.
Поскольку ставлю, следующее
 

default_destination_rate_delay=1s

или

smtp_destination_rate_delay = 1s

.
 То задержка, становится от 5-8 секунд, согласно логам  maillog.
 Вопрос как отправлять именно 29 сообщении в минуту, не больше и не меньше?

Нет, токены даёт клиенту auth-сервер. Rp сервер должен лишь получать от клиента id-токен и auth-токен для идентификации, аутентификации и авторизации пользователя. Refresh-токен после выдачи клиенту покидать клиент не должен