Ключ живёт 900 секунд допустим. И если запросить слишком много ключей не уничтожив старые - заблокирован доступ на создание новых ключей на некоторое время

Все равно нужны доп уровни абстракции. Если есть только тесты, то интеграцию проверять будет сложно. Должен быть клиентский слой, который можно переиспользовать в тестах. Можно разбивать по рутам эндпоинтов и объединять фасадом, как уже предлагали выше (если микросервисы). С монолитом достаточно просто разбить по рутам. Ну + кеширование токена и самих клиентов (при необходимости сохранять стейт между вызовами).

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

но вообще звучит все это так себе)

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

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

Вот да

ну тут нет решения, задача выглядит мягко говоря стремной

из того что приходит на ум:
1. сильно понижать время жизни сессии у провайдера, например секунд 30-60
2. чтобы клиенты чаще запрашивали токены если активно их юзают
3. да, задолбишь свой провайдер токенов запросами, но хотя бы не так много ждать при превышении пула
4. какой нибудь force флаг, который убьет самую старую сессию, лишь бы создать новую тому кому важнее
5. сделать сессии реюзабельными, чтобы несколько пользователей могли использовать одну сессию

Ну почему? Есть похожие задачи с пуллом одобренных тестовых юзеров на проде, которым можно что-то делать в тестах, а потом "чиститься". Напоминает такую же ситуацию с сессиями. Если это неотъемлимые реалии проекта, то чуваку просто нужно написать data provider для своих тестов, и этого будет достаточно. А всю логику создания, инвалидации, отслеживания количества сессий инкапсулировать уже в него, и в тестах об этом не думать.

Спасибо, попробую.

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

Я буду просто контролировать ключ на стороне прослойки

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

Речь о превышении лимитов для одного конкретного тех юзера, от имени которого отдаются токены?

Да

А провайдер чей-то готовый или самописный?

Провайдер сам уничтожает ключ по сле какого-то времени, поэтому всегда будет один ключ

Для меня это черный ящик, не знаю как и кто реализовал

Он говорит о другом. Что ты запустишь 100 тестов, и твой сервис нагенерит до отказа сессий, от чего у кого-то другого отвалится возможность логиниться.