根据我所知道的（如果我错了，请纠正我），"access_token"相当于AspNetUser表中的"protected ticket"字段。它只是被打乱了。
我计划做的是反序列化受保护的票证以获得access_token值。
我正在尝试支持SSO场景，其中用户可以使用相同的访问令牌访问多个应用程序。
不幸的是，如果使用的哈希函数是一个加密哈希，根据情况，这在定义上是不可能的（或者应该是…）。加密哈希函数被设计为非常昂贵（理想情况下是不可能）的反向，因此最有效的方法是尝试暴力破解哈希，也就是说，通过散列函数运行输入，直到得到一个产生所需输出的函数。即便如此，也不知道你需要多长时间才能找到它。强烈建议不要写任何依赖于常规暴力加密哈希的东西。
当然，可能的输入非常小（即最多16位左右），或者使用的函数不是加密哈希函数（即它类似于base64编码或rot-13）。在这种情况下，您可能有一种方法可以有效地反转"哈希"。
然而，我强烈怀疑事实并非如此。在这项努力中，我认为你只是运气不佳，必须找到另一种方法来获得你想要的功能。
我觉得我有点晚了，但应该是可能的。ProtectedTicket的数据将由Microsoft.Owin.Security.SecureDataFormat.Protect保护。它不是单向哈希。所以它可以逆转。你可以在Katana项目（微软的Owin实现）的Github上查找这个：
https://github.com/aspnet/AspNetKatana/blob/dev/src/Microsoft.Owin.Security/DataHandler/SecureDataFormat.cs
如您所见，此接口还提供了一个方法Unprotect。没有测试，但你可以尝试一下。
您可以在相同的应用程序上使用相同的令牌，只要jwt令牌在每个应用程序上都使用相同的凭据（访问者和机密）进行签名。这允许每个应用程序验证令牌是否有效。这意味着，无论如何，每个应用程序都必须知道后端中的受众id和秘密