Lexikjwtauthenticationbundle: Configure multiple lexik_jwt_auth

[Taluu]

Kinda linked to #504, but here goes ;

It could be great to be able to set multiple configurations for the config name, by using a prototype in the config. As does doctrine for example to be able to configure multiple entity managers / connections, so we can inject the jwt authentication we need.

e.g

lexik_jwt_authentication:
    api:
        secret_key: 'secret_key'
        token_ttl: 3600
        encoder:
            signature_algorithm: HS256

    other:
        secret_key: 'secret_key'
        token_ttl: 60
        encoder:
            signature_algorithm: HS256

[fl0cke]

Would be really nice to have this feature 👍

[badrutdinovrr]

As soon as Symphony lacks multiple bundle instances support and it seems @lexikteam is not interested in this issue, here is a workaround.

First of all, DI gives us ability to override any part of the bundle. A hint how to make many authenticators is given here

We have to define another authenticator on our own using existing configuration.
Given the application with client and admin api (^/api/client and ^/api/admin respectively), we have to add another guard (config/security.yaml):

security:
    firewalls:
...
        admin:
            pattern: ^/api/admin
            anonymous: false
            lazy: true
            provider: jwt

            guard:
                authenticators:
                    - app.jwt_admin_authenticator
...

Here we use another authenticator, whose config looks like (config/services.yaml):

....
app.jwt_admin_jws_key_loader:
        parent: lexik_jwt_authentication.key_loader.raw
        arguments:
            index_0: '%env(JWT_ADMIN_SECRET_KEY)%'

    app.jwt_admin_jws_provider:
        parent: lexik_jwt_authentication.jws_provider.lcobucci
        arguments:
            index_0: '@app.jwt_admin_jws_key_loader'
            index_2: '%lexik_jwt_authentication.encoder.signature_algorithm%'

    app.jwt_admin_encoder:
        parent: lexik_jwt_authentication.encoder.lcobucci
        arguments:
            index_0: '@app.jwt_admin_jws_provider'

    app.jwt_admin_manager:
        parent: lexik_jwt_authentication.jwt_manager
        arguments:
            index_0: '@app.jwt_admin_encoder'
            index_2: 'systemUserId'
        calls:
            - [setUserIdentityField, ['systemUserId']]

    app.jwt_admin_authenticator:
        parent: lexik_jwt_authentication.jwt_token_authenticator
        arguments:
            index_0: '@app.jwt_admin_manager'
....

So, you can just assemble your own JWT authenticator using existing components. Unfortunately this approach can cause to tight coupling with bundle structure since you have to know how to build necessary objects.

[fd6130]

Yea this multiple config for jwt is nice because we can have multiple provider in security. Hope someone could implement this feature for this bundle :(

[TonyBogdanov]

+1 for this!

In my setup I'm using JWT authentication for regular users, but I'm also using Google Cloud Pub/Sub with push endpoints, which I obviously need to firewall somehow. Google supports authenticating its requests with a JWT token generated for a service account, so all I need to do is verify that token against the service account.

The bundle works nicely to achieve this, the only problem is I can't use separate key pairs for Pub/Sub and my regular users, which is a disastrous security hole.

I'll have to explore @badrutdinovrr's custom authenticator workaround.

[chalasr]

With the new Symfony authenticator-based security system, we are probably going to move most of the config to per-firewall configuration (with a lexik_jwt: ~ configurable authenticator). Would that fit your use cases?

[TonyBogdanov]

With the new Symfony authenticator-based security system, we are probably going to move most of the config to per-firewall configuration (with a lexik_jwt: ~ configurable authenticator). Would that fit your use cases?

Yes, that would actually be the best solution. I've been looking into the new approach and it really does simplify things a lot! Too bad it'll be mostly used in Symfony 6.0, which in my mind, is to be widely adopted in at least a couple of years...