JWT是一个标记字符串，由三部分组成，三部分之间用点分隔字符。

每个部分都是Base64编码（未加密）的，因此您可以通过Base64单独解码每个部分来获取每个部分的内容。因为Base64编码的数据不包含点'字符这使得在任何情况下都可以使用它作为分隔符来连接这三个部分。

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

• 用于签名的算法
• JSON格式的信息性内容
• 签名

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

• 将JWT拆分为点'.'字符
• 采取第二部分和Base64-decode它

必须考虑的是，JWT中包含的信息不会被读取保护，它会被保护免受修改；因此，在不了解证书或加密密钥的情况下解码和访问这些信息并没有什么错。

与令牌相关的整个过程有三个参与者：

• 发行者：通常是一个身份验证API
• 承载：通常是API客户端应用程序
• 消费者：通常是需要它响应的API

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

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

消费者和发行者通常（但不一定）只是同一应用程序的不同API方法。

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

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