Владимир Дубровин

Это слишком общий вопрос.

В целом, хранить сами токены не стоит ни в каком случае, для сравнения всегда достаточно хранить хеш.

В случае если вы используете JWS, хранение токенов может потребоваться чтобы иметь возможность отозвать токены при завершении сессии пользователем. Обычно хранится не сам токен, и даже не хеш, а идентификатор сеанса. При этом можно хранить либо список активных сессий либо наоборот список отозванных (в течении времени жизни рефреш токена). Фактически это убивает все преимущества JWS, но другого способа завершить сеанс нет, это глобальная проблема JWS. Поэтому использовать JWS для рефреш токенов в целом не очень разумно.

Про запрет повторного использования вам ответили, но в целом такой запрет является опциональным, в большинстве реализаций OAuth2 новый рефреш не возвращается и старый токен остается действительным.

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

Второй вариант достаточно безопасен при правильной реализации, однако там есть много подводных камней. Достаточно подробно они и возможные атаки на клиентский OAuth разобраны в этой статье.

Хэш используется для предотвращения утечек токена наружу, например через Referer страницы.

Используйте TLS (https) и куки с флагом HTTP Only и Secure. В качестве куки лучше использовать достаточно длинный случайный идентфикатор сеанса.

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

Можно дополнительно привязать куку к автономной системе (AS) и браузеру, но реальной дополнительной защиты это не дает. Привязка к IP ре рекомендуется, т.к. IP может достаточно часто меняться у пользователя, особенно мобильного.

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

Чаще всего делается схема refresh token + access token, т.к. она является легко масштабируемой.
1. Пользователь авторизуется на сервере авторизации по телефону, приложение получает refresh token (постоянно действующий), постоянно хранит этот токен безопасным способом.
2. При старте приложения и с некоторой регулярностью (например раз в 10 минут) или при необходимости обращения к определенному API фронт-сервера, приложением дергается API сервера авторизации с refresh token и получается access token, короткоживущий (например 15 минут). access token может быть некоторой информацией - id пользователя, timestamp, запрошенный тип сервиса и т.п. - подписанной (или зашифрованной) ключом сервера авторизации.
3. Приложение обращается к API front-серверов с access token, фронт-сервер валидирует токен
4. При разлогине (или смене пароля если он будет) инвалидируется refresh token. access token'ы "протухают" самоходом в течении интервала жизни.

Это дает:
1. совместимость с OAuth, можно использовать вход через сторонние сервисы и наоборот предоставлять им возможность что-то делать за пользователя.
2. централизованную авторизацию пользователя и управление сессиями (все токены раздаются сервером авторизации)
3. возможность завершения сессии на стороне сервера (сервер авторизации инвалидирует refresh token)
4. возможность централизовано давать или не давать доступ к отдельным концам API или серверам (через включения типа сервиса в сессионный токен, для каждого API или сервиса можно запрашивать разные токены, которые будут действительны только для них). Так же можно разделить зоны безопасности, например запрашивать отдельный токен для обращения к менее защищенным сервисам, который не даст доступа к более привилегированным сервисам.
5. фронт-серверам не требуется проверять каждый запрос на сервере авторизации, они самостоятельно могут проверить правильность таймстампа/подписи и соответсвтие типа токена запросу.

Использование JWT или других механизмов уже определяется структурой приложения. Лучше использовать стандартный механизм, чтобы избежать "самопальной" криптографии.

P.S.
иногда схема усложняется до refresh_token (постоянный) + session_token (временный) + access_token (на доступ к кокретной ручке или сервису)