JWT RS256 是否需要 OpenSSL?无法在 PHP 中解码 JWT

Sib*_*ecy 2 php ssl openssl jwt

我们的证书是 Comodo Positive SSL。
我们正在尝试使用 Php 和https://github.com/firebase/php-jwt这个库解码从“使用 Apple Id API 签名”给出的 JWT 。当我们运行 decode 它会给我们

A PHP Error was encountered
Severity: Warning

Message: openssl_verify(): supplied key param cannot be coerced into a public key

Filename: php-jwt/JWT.php

Line Number: 231

Array ( [status] => [message] => OpenSSL error: error:0906D06C:PEM routines:PEM_read_bio:no start line )
Run Code Online (Sandbox Code Playgroud)

我们不知道该怎么办.. 如果我们将 RS256 更改为 HS256,它会给我们

Array ( [status] => [message] => Algorithm not allowed )
Run Code Online (Sandbox Code Playgroud)

Die*_*aro 6

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

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

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

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

因此,为了检索令牌带来的信息,需要:

  • 在点'.'字符处拆分 JWT
  • 拿第二部分,Base64-decode它

必须考虑到 JWT 中包含的信息不受读取保护,它受到保护不被修改;因此,在不了解证书或加密密钥的情况下能够解码和访问此信息并没有错。

与token相关的整个过程有3个参与者:

  • 在发行人:通常认证API
  • 在承载:通常API客户端应用程序
  • 在消费者:平时API,它要求作出回应

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

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

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

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

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