Closed Tilogorn closed 7 months ago
Hello @Tilogorn ! Thanks for filing this feature request. Your issue is the first that actually details a valid use-case.
I would love to help you support this feature, now that I know it's preventing you from using this library. The problem is, I am not sure how we can support it at this point without breaking backwards compatibility.
Some potential ways to support it (just brainstorming)
Firebase\JWT\JWT::$typ = 'JOSE';
JWT::encode
public static function encode(
array $payload,
$key,
string $alg,
string $keyId = null,
array $head = null,
string $typ = 'JWT',
): string {
and this could be called by:
$jwt = Firebase\JWT\JWT::encode(payload: $payload, key: $key, typ: 'JOSE');
This works great since we already have alg
, which is analogous to typ
. It's not ideal that the $alg
and $typ
parameters are not in any sensical order.
$head
and $header
in the call to array_merge
$header = \array_merge($header, $head);
This would break BC in a case where $head
contained a typ
parameter (and it also it makes the $alg
parameter silly), but that risk is small enough that it might be worth it.
I am personally leaning towards the third option. Any thoughts?
Hi @bshaffer, I am pleased that you are aware of my concern.
I would also vote for the third option. The amount of devs who needed to change the typ
header and were not able to do so should not face any issues. They had either been changing their client library as I did or changed the JWT validation on the server side to meet the current implementation requirements of Firebase\JWT
– if there were able to modify that part (which I am not). The last one would only be a problem if they forgot to unset the $head['typ']
in their current call to JWT::encode
and I think that case is so edgy that you can take the risk.
THis is released in v6.10.0. Please confirm that this resolves your issue!
@bshaffer did not forget you and will def try it out and report back. I'll have to implement new features in Q1/24 for the same project, that's a good opportunity.
I know it has already been issued/discussed in https://github.com/firebase/php-jwt/issues/472 and https://github.com/firebase/php-jwt/issues/418 but got closed without result.
I need to change the
typ
header toJOSE
, which is sort of a pre-defined value for it, see last paragraph of this RFC 7515 chapter. The "need" is just the result of a requirement by the interface I want to talk to, which verifies that thetyp
header of my JWT equalsJOSE
. I am not in a position to argue for or against the point of it.I already use
php-jwt
on other parts of my application and love the interface and simplicity of it and I am now forced to integrate another JWT library just because you insist onJWT
hardcoded (source).Any chance you'll reconsider that decision?