Meta/Feedback: Change JWT library from lcobucci/jwt to web-token/jwt-framework

[bradjones1]

I'm not aware of the specific history of choosing a JWT library to use, but the conversation at #1007 (comment) leads me to ask the question, how difficult would it be to swap out lcobucci/jwt for web-token/jwt-framework?

Both appear to have active development/maintainers, though neither has a particularly rapid release cadence. The main compelling reason to select a new library would be for more complete out of the box support for JWT-related RFCs, e.g. RFC 7517 for JWKs (re: the issue linked above.)

I'm not trying to create any unnecessary bikeshedding or tribalism, but if it would be "easy enough" to choose a new underlying library, we may get some advantage in rolling out new features. Thoughts?

[chris-doehring]

A contributing factor could be that lcobucci/jwt is blocking php 8 compatibility right now, while web-token/jwt-framework allows php 8 usage. Looking at the current state of lcobucci/jwt, I'm not sure whether there will be a v4.0 release before php 8 GA.

EDIT: The maintainer of jwt confirmed the intention to release v4.0 close to the php 8 GA.

[Spomky]

Hi there,

My 2 cents on this conversation.
I am the author of the JWT Framework and I will be happy to help you implementing that framework. I’ve worked a lot on the OAuth2 framework protocol and quite familiar with all the associated concepts.

As I develop, I realized that we should not depend on an implementation or the other. Now, that’s why I try to be “framework agnostic”, whatever it is. This includes the framework I manage.
What I am trying to explain here is: you should not require lcobucci/jwt or web-token/jwt-framework. From my POV, it is preferable to rely on interfaces/abstractions you manage and have adapters for libraries.

As an example, I am working on a new version of the web-push lib. This library needs JWT and provides adapters for both lcobucci/jwt or web-token/jwt-framework, but none of them is required. The core library relies on simple interfaces and DTOs.

From my POV, you should not choose between one lib or the other, but provide an elegant way to allow devs to use the one that best fit on their projects.
I am certain lcobucci/jwt will be updated as it is used by lots of projects. It’s just a question of time. So no reason to drop it in favour of another lib.

[Sephster]

At the moment, we don't have plans to replace the usage of lcobucci's JWT library. If there wasn't a PHP 8 compatible release prior to the GA we might have to revisit this decision but I understand a new release will be forthcoming soon.

We primarily use the JWT library to read incoming bearer tokens. However, this can be easily replaced with another JWT lib if you wish. The BearerTokenValidator class implements the AuthorizationValidatorInterface.

If you don't want to use the BearerTokenValidator you can write your own, then pass it to the ResourceServer via its constructor.

Thanks to @Spomky for taking the time to reach out to this issue and for everyone elses input regarding this.