Тут много зависимостей, которые не раскрыты. Механизм сессий может быть очень сильно разным. Начиная от простейшего штатного, где сессия прекращается через 1440 секунд бездействия (заметьте, это много менее нескольких часов действия токена) и до навороченного с "вечным" хранением пользовательских данных в БД.
В последнем случае токен, привязанный к юзернейму вполне можно хранить в пользовательской сессии.
Если же использован простой механизм сессий, а токен привязан к юзернейму, то и хранить его где-то в таблице свойств юзера есть смысл. Впрочем, несложно заметить, что и первый и второй вариант по сути хранят токен в базе.
Ну и вариант, когда токен выдается Сайту... Понятно, надеюсь, что хранить такой токен есть смысл на уровне свойств/настроек сайта.

Хранилище сессий глобальное, конечно. Бывает глобальное для сайта, unix-аккаунта, сервера - это уж как настроено.
Каждая сессия в простом варианте уникальна для посетителя и ее имя (и имя файла для хранения данных) явно привязано к куке, которую получает/присылает пользователь.

Где-то на сайте есть таблица пользователей с их учетными именами? Можно там, в принципе, хранить.
Или вот еще хороший вариант - можно мемкеш задействовать для хранения. Запоминать в нем пару варнейм=>токен (где варнейм содержит учетное имя пользователя) на время равное или чуть менее времени годности токена. Притом, логика простая получается. Если мемкеш вернул данные - использовать их, если не вернул - запрашивать токен, сохранять его и использовать в текущем обращении.

Ух, как завернули!

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

Другими словами, не получится ли так, что сертификат уже непригоден, а токен вполне себе живой. Наверно, этот момент тоже как-то следует учесть. С плановым окончанием срока годности вполне понятно. Но как учесть досрочный отзыв сертификата без дополнительного обращения к Сервису?

Тогда для чего эту проверку замутили?