Как сохранить токены обновления OAuth 2

Не могу найти никаких рекомендаций о наилучшем способе реализации персистентности токенов обновления OAuth 2 и какого-либо общего мнения о том, что на самом деле следует хранить и как.

Хотя есть очень хороший тоториал Тайсир Джоуде о разрешении OAuth в ASP.NET веб-API. Это таблица RefreshTokens из статьи:

Где: Id - хэш уникального идентификатора токена, Subject - имя пользователя, ClientId - заявка identifier, ProtectedTicket - сериализованный маркер доступа.

Я хотел бы доказать или опровергнуть некоторые решения, принятые там с помощью сообщества SO. Итак, вот мои опасения:

1. Почему мы должны сохранять недолговечный access_token ? До сих пор я могу назвать две причины, по которым такой подход оправдан. Во-первых , потенциально это может быть угрозой безопасности, когда вы сохраняете галочки доступа пользователя в любом месте, просто ожидая, что кто-то захватит их и повторно использует для ничего не подозревающего сервера ресурсов (помните, что они должны использовать тот же алгоритм для сериализации / десериализации ключей). Во-вторых, вам придется позаботиться об обновлении этих сохраненных билетов, как только вы решите изменить любую часть алгоритма сериализации. Итак, почему бы нам просто не создать новые билеты во время выполнения после проверки client_id и refresh_token вместо чтения и десериализации из базы данных?

2. Как access_token должен быть зашифрован , если мы должны сохранить его? Будет ли salt + SHA2 на сериализованном билете выполнять эту работу или есть лучший способ?

3. Почему хэш refresh_token id ? От каких видов атак он на самом деле защищает? И не будет ли это более безопасно, если мы отправим хэшированные ключи как refresh_token, сохраняя реальный ключ в базе данных? Таким образом, грубая атака на refresh_token (угадывание маркера обновления случайного пользователя) также должна была бы угадать алгоритм хэширования.