Следует для начала определиться, а зачем в данной ситуации вообще использовать bcrypt.
У bcrypt есть свои преимущества, недостатки и цели применения. Этот алгоритм хорош для паролей по той причине, что у него высокая вычислительная сложность и низкая скорость перебора, если злоумышленники утащат базу данных - то подобрать для паролей коллизии займёт очень много времени, если вообще им захочется этим заниматься.
Хэшировать этим алгоритмом токены не имеет никакого практического смысла, т.к. содержимое токена не представляет для злоумышленника никакой ценности - "публичная" часть собирается из данных, хранящихся в той же БД в открытом виде (id пользователя, емейл), а подпись - легко инвалидировать, сменив секрет после утечки БД.
Если же просто нужно в каком-то хэшированном виде хранить хэши токенов для сравнения между собой, то лучше воспользоваться любой "легковесной" хэш-функцией, например, sha1 (да или тупо в открытую хранить подписи токенов без самих токенов и уже их сравнивать). Много вычислительных раундов и соль в этой задаче абсолютно лишние по вышеуказанной причине. В большинстве случаев их и хранить не обязательно, достаточно проверять их подлинность после получения от клиента (хранить разве что в ситуации, когда есть механизм отзыва токенов и нужно проверять, не отозван ли он).
