私はあなたの質問を読んで、無記名トークンがどのように暗号化または署名されているかをインターネットで検索することに成功せずに試みました。ベアラートークンはハッシュされていないと思います（多分部分的ではあるが完全ではないかもしれません）。その場合、それを解読してそこからユーザーのプロパティを取得することができないからです。
しかし、あなたの質問はベアラートークン機能の答えを見つけようとしているようです：
承認プロバイダーを実装しているとしましょう。無記名トークンに任意の文字列を指定できますか？ランダムな文字列にすることはできますか？一部の属性のbase64エンコードである必要がありますか？ハッシュ化する必要がありますか？
そこで、ベアラートークンとリフレッシュトークンのしくみについて説明します。
ユーザーがSSLを介してトークンを送信するユーザーとパスワードをサーバーに要求すると、サーバーはアクセストークンと更新トークンの 2つを返します。
アクセストークンは、具象ユーザーとして認証されるすべてのリクエストヘッダーに追加する必要があるベアラートークンです。
Authorization: Bearer <access_token>
アクセストークンは、必要なすべてのユーザープロパティ、クレーム、および役割を含む暗号化された文字列です。（ロールまたはクレームをさらに追加すると、トークンのサイズが増加することを確認できます）。リソースサーバーは、アクセストークンを受信すると、それを復号化してこれらのユーザープロパティを読み取ることができます。このようにして、ユーザーはすべてのアプリケーションとともに検証および許可されます。
アクセストークンの有効期限は短い（つまり、30分）。アクセストークンの有効期限が長い場合、理論的には取り消すことができないため、問題になります。したがって、「User」に変わるrole = "Admin"を持つユーザーを想像してください。ユーザーがrole = "Admin"で古いトークンを保持している場合、管理者権限でトークンの有効期限が切れるまでアクセスできます。これが、アクセストークンの有効期限が短い理由です。
しかし、1つの問題が頭に浮かびます。アクセストークンの有効期限が短い場合、短い期間ごとにユーザーとパスワードを送信する必要があります。これは安全ですか？いいえ、そうではありません。避けるべきだ。これが、更新トークンがこの問題を解決するように見えるときです。
更新トークンはDBに保存され、有効期限が長くなります（例：1か月）。
ユーザーは、トークンの最初のリクエストで受け取った更新トークンを使用して、新しいアクセストークンを取得できます（有効期限が切れると、たとえば30分ごと）。アクセストークンの有効期限が切れると、クライアントは更新トークンを送信する必要があります。この更新トークンがDBに存在する場合、サーバーはクライアントに新しいアクセストークンと別の更新トークンを返します（古い更新トークンを新しい更新トークンに置き換えます）。
ユーザーアクセストークンが侵害された場合、そのユーザーの更新トークンをDBから削除する必要があります。この方法では、ハッカーが更新トークンを送信する新しいアクセストークンを取得しようとすると、このアクションが拒否されるため、トークンはアクセストークンの有効期限が切れるまでのみ有効です。