JWT RS256是否需要OpenSSL?无法在PHP中解码JWT [英] Does JWT RS256 requires OpenSSL? Can't decode JWT in Php

问题描述

我们的证书是Comodo Positive SSL.
我们正在尝试使用Php和 https://一起对使用Apple Id API签名"给出的JWT进行解码github.com/firebase/php-jwt 这个库. 当我们运行解码时，它会给我们

Our certificate is Comodo Positive SSL.
We are trying to decode JWT which is gived from "Sign with Apple Id API" using Php with https://github.com/firebase/php-jwt this library. When we run decode it gives us

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 )

我们不知道该怎么办.如果我们将RS256更改为HS256，它将为我们提供

We don't know what to do.. If we change RS256 to HS256 it gives us

Array ( [status] => [message] => Algorithm not allowed )

推荐答案

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

JWT is a token string which is composed by three parts separated by a dot '.' character.

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

Each part is Base64-encoded (not encrypted) so you can get the content of each part by Base64-decoding each part individually. Since Base64-encoded data does not contain the dot '.' characters this gives the possibility to use it as a separator to join the three parts in any case.

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

The content of the three sub strings, once the JWT has been split and each individual part Base64-decoded is as follows:

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

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

So in order to retrieve the information brought by the token it is needed to:

• 将JWT分隔为点'.'个字符
• 参加第二部分，然后Base64-decode

• Split the JWT at dot '.' characters
• Take the second part and Base64-decode it

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

It has to be considered that the information contained in a JWT is NOT protected by being read, it is protected against modification; so there is nothing wrong in being able to decode and access this information without knowledge of certificates or encryption keys.

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

The whole process related to the token has three actors:

• 发布者:通常是身份验证API
• 载体:通常是API客户端应用程序
• 消费者:通常是要求其响应的API

• the issuer: usually an authentication API
• the bearer: usually the API client application
• the consumer: usually the API which requires it to respond

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

The third part of the token, the signature, is the element that allows the consumer to be sure the token has not been modified and, for that reason, that the information contained in it can be trusted because had been checked/provided by the issuer.

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

The bearer is not expected to be able to check the token: it is just expected to receive it from a verification procedure and give it to the API it wants to use. It can eventually access the content, meaning that in the context of the application an access to the token information by the client that received it does not have to constitute a vulnerability. The token has to be delivered to the client (and sent back to the consumer) over a protected channel like SSL / https and this is to protect access to the token by other entities, not by the client which the token is being delivered.

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

The consumer and issuer are often (but not necessarily) just different API methods of the same application.

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

The algorithm used for the signature can be a symmetric or asymmetric encryption one. In the first case the encryption key has to be shared between the issuer and the consumer. Although this may seem a problem it actually is not the case in situations (a quite common case) where the issuer is also the consumer (or at least they are in the same host). In this case the "shared secret" is indeed not shared with anyone.

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

When the consumer (one or more) needs to be separated by the issuer then an asymmetric encryption can be used so that the issuer keeps the private key and the consumer just have the public key. In this case of course also a symmetric encryption can be adopted but the "shared secret" has to be really shared with the different consumers so evaluations must be done if this can be safely done and maintained.

这篇关于JWT RS256是否需要OpenSSL?无法在PHP中解码JWT的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！