а в чём риск ? в плане того, что разные провайдеры могут поддерживать или нет и это может стрельнуть на смене условного keycloak на okta (ну т.е. на конкретных реализациях) ? или в чём-то другом ?

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

Впрочем, не уверен, что вообще для этого есть стандартные реализации (кроме, наверно, спринга, там вообще все есть)

тогда да, согласен

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

смотря кто диктует правила игры/интеграции :) наверное

Для чего "этого" ?

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

Для клиентской библиотеки с реализацией Client Credentional Flow с конкретными методами аутентификации из https://tools.ietf.org/html/rfc7523, например.

Это ж просто набор хттп запросов, которые надо выполнить в определённом порядке? Для этого точно нужны библиотеки (на случай, если их, конечно, нет) ?

Зная наших клиентов - лучше, если будут )
Но вообще если там дальше двутокенная схема, например, то все уже становится не очень тривиальным для многопоточного приложения.

на мой взгляд сфера применения JWT это одноразовая передача некоторых данных от сервиса к сервису через клиента

А зачем "двухтокенная система" ?
Вы в своём приложении работаете с одним токеном, подписанным тем сервером, которому вы доверяете (==публичный ключ которого вам известен), в нём написано кому он выдан и сколько действует.  Токен приколочен к запросу (через заголовок обычно), вы проверяете подпись и на этом всё - вы знаете от кого этот запрос.  Трудности с многопоточностью могут быть только при выдаче токенов, в случае если у вас какое-нибудь CryptoPro JCP со своими самоизменяющимися ключами.
Как внешняя система этот токен получает - это её личные половые трудности, примеров получения токенов по openid-connect/oauth2 полон Интернет.  Справедливости ради следует отметить, что в некоторых случаях есть нюансы - когда мы делали модуль для логина в ЕСИА через Keycloak выяснилось что такой запрос надо подписывать по ГОСТ.

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

Для back-2-back двутокенная схема обычно не нужна, для front-2-back позволяет обнаруживать компрометации клиента.

Впрочем, если на back-2-back есть риски "несанкционированных бэкендов", то двухтокенная схема тоже имеет смысл.

Сделайте входную аутентификацию на клиентских сертификатах, выдаваемых вашим УЦ - обычно помогает от лишних соединений :-)

Увы, это дает довольно мало защиты от опсов )

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

(Так как число людей, умеющих настраивать TLS очень небольшое, а уж число опсов, умеющих следить за временем жизни ключей близко к нулю)