bobo96 , речь я так понимаю про OAuth2. Так вот, сервисы внутри одной организации не должны общаться с помощью токенов пользователя . Эти токены и пользовательская авторизация созданы для того чтоб пользователь выдал права на свои личные ресурсы 3d-party сервисам.
Например, ты хочешь дать доступ этому форуму к своим фоткам в гугле. Тогда этот форум перекинул бы тебя на гугловскую страницу авторизации. И ты сказал бы гуглу "вот этому форуму дай мои данные". Тогда форум получает токен, обращается с ним к гуглу, и тот его проверяет в своем Auth Server'e. Заметь что гугл не доверяет по умолчанию этому форуму, это твои обязанности определить каким сервисам доверять.

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

PS: можешь спокойно игнорировать петро. Он пользы не принесет. А если начнешь с ним общаться, то тут начнется очередной флуд и нормальные разработчики сюда не прийдут.

Если все-таки захочется использовать тот же OAuth2, то там есть специальный Client Credentials Workflow - он позволит аутентифицироваться сервисам (aka клиент). Это не пользовательский токен (то называется User Authorization Workflow). В случае Client Credentials Workflow обычно используется JWT:
1. Сервис аутентифицируется в Auth Server'e, получает подписанный JWT токен
2. Resource Server (тот к кому мы обращаемся) должен быть настроен чтоб он доверял подписи Auth Server'a. Тогда в самом JWT хранится expiration date, а также он подписан и ему можно доверять.

В таком подходе серверу не нужно будет никуда идти и проверять валиден ли токен - сервер сам это делает. Это усложнение с подписями нужно чтоб серверу не приходилось часто ходить в Auth Server. Было бы плохо для производительности.

PS: и да, чтоб не было путаницы - к SSO это все не имеет никакого отношения

Sergunka, это как раз тот workflow который ему не нужен. Ему максимум нужен Client Credentials grant.