问JWT RS256需要OpenSSL吗？无法在Php中解码JWT

EN

JWT是一个令牌字符串，它由由一个点'.'字符分隔的三个部分组成。

每个部分都是Base64-encoded (未加密)，因此您可以通过Base64 64获取每个部分的内容--对每个部分进行单独解码。由于case 64编码的数据不包含点'.'字符，因此在任何情况下都可以使用它作为分隔符来连接这三个部分。

三个子字符串的内容，一旦JWT被拆分，并且每个单独的部分Base64 64-解码如下：

用于JSON signature

• informative format

• signature

内容的

• 算法

因此，为了检索令牌带来的信息，需要：

characters

• Take第二部分
• 将JWT拆分，Base64-decode it

必须考虑的是，JWT中包含的信息不是通过读取来保护的，而是受保护的，不受修改；因此，能够在不知道证书或加密密钥的情况下解码和访问这些信息并没有错。

与令牌有关的整个过程有三个行为者：

application

• the
• 颁发者：通常是一个身份验证API
• 承载：通常是API客户端使用者E 231：通常是需要它响应H 232F 233的API

令牌的第三部分，即签名，是允许使用者确保令牌没有被修改的元素，因此，其中包含的信息可以信任，因为签发人已经检查/提供了这些信息。

承载者不能检查令牌:它只希望从验证过程中接收到令牌，并将其交给它想要使用的API。它最终可以访问内容，这意味着在应用程序的上下文中，接收到令牌信息的客户端对令牌信息的访问不必构成漏洞。令牌必须通过受保护的通道(如SSL / https )传递给客户端(并发送回使用者)，这是为了保护其他实体()对令牌的访问，而不是由正在传递令牌的客户机访问令牌。

使用者和发行者通常(但不一定)只是同一应用程序的不同API方法。

用于签名的算法可以是对称加密算法，也可以是非对称加密算法。在第一种情况下，加密密钥必须在发行者和使用者之间共享。虽然这似乎是一个问题，但在发行人也是消费者(或至少在同一个主机上)的情况下(相当常见的情况)，情况并非如此。在这种情况下，“共享的秘密”确实不会与任何人分享。

当使用者(一个或多个)需要由发行人分隔时，就可以使用非对称加密，以便发行人保留私钥，而使用者只拥有公钥。当然，在这种情况下，也可以采用对称加密，但“共享秘密”必须真正地与不同的使用者共享，因此，如果能够安全地完成和维护，就必须进行评估。