Hi,

Is it possible to put this PR on hold?
The reason is that algorithms from theweb-token/ suite will be grouped and, very soon, withweb-token/jwt-library you will have all at once (including encryption to help#50441)

Hi@louismariegaborit,

Can you test with"web-token/jwt-library": "3.3.0@dev" adn"ext-openssl": "*"?
Both web-token/jwt-signature-algorithm-ecdsa andweb-token/jwt-signature-algorithm-rsa dependencies can be removed.

Also, because the newweb-token/jwt-library contains more thanESxxx andRSxxx algorithms, I am wondering if this PR could be renamed to[Security] Support any signature algorithms for OIDC tokens and allow developers picking the algorthims they need.

Note:web-token/jwt-library will be tagged in a couple of days.

Hi@Spomky

This seems ok. I removed alsoweb-token/jwt-checker.
For theext-openssl, I added it in the require-dev but it's in suggest like in your repository that you want that be added ?

I will look so that developers picked the algorithms they need.

I will update the PR title when we validate the work.

@Spomky I did a try. WDYT ?
I don't know if I can delete old algorithm services without deprecations. And if I keep the services with deprecations, could you tell me how do it ?

This seems ok. I removed also web-token/jwt-checker.
For the ext-openssl, I added it in the require-dev but it's in suggest like in your repository that you want that be added ?

Indeed, most ofjwt-* packages are now underjwt-library.
OK forext-openssl in therequired-dev section. I'll make sure the algorithms complain if it's missing.

@vincentchalamon do you have any recommendation to have a better algorithm support architecture.
What could be interesting is to allow multiple algorithms

# config/packages/security.yamlsecurity:firewalls:main:access_token:token_handler:oidc:# Algorithms used to sign the JWSalgorithms:                            -'ES256'                            -'RS256'                            -'PS256'# A JSON-encoded JWKkey:'{"kty":"...","k":"..."}'

From my understanding, it will require:

• If the configuraition keyalgorithm is present: to normaliwe the current configuration fro;["algorithm" => $alg] to["algorithms" => [$alg]]
• Change theOidcTokenHandler first argument to accept an algorithm manager object instead a single algorithm
• Use thealgorithm manager factory to create the algorithm manager according to the configuration

Any ideas on this?

@vincentchalamon do you have any recommendation to have a better algorithm support architecture. What could be interesting is to allow multiple algorithms

# config/packages/security.yamlsecurity:firewalls:main:access_token:token_handler:oidc:# Algorithms used to sign the JWSalgorithms:                            -'ES256'                            -'RS256'                            -'PS256'# A JSON-encoded JWKkey:'{"kty":"...","k":"..."}'

From my understanding, it will require:

• If the configuraition keyalgorithm is present: to normaliwe the current configuration fro;["algorithm" => $alg] to["algorithms" => [$alg]]
• Change theOidcTokenHandler first argument to accept an algorithm manager object instead a single algorithm
• Use thealgorithm manager factory to create the algorithm manager according to the configuration

Any ideas on this?

@Spomky I started this work in another PR (#51665).
I still need to support an array for the algorithms.
I think, we must decide what is the responsability of each PR.

@Spomky on an OIDC server (e.g.: Keycloak), is it possible to allow multiple algorithms on a single realm?

If true, multiple algorithms configuration could be interesting, indeed. I'm just wondering if thekey configuration (JWK) shouldn't be associated to the corresponding algorithm, as I think they're linked (cf. JWA).

If false, I don't think we should allow multiple algorithms configuration as multiple realms are not supported.

Hi@chalasr,

It seems to be fine now.
I corrected one of the tests without the@group legacy. Other errors are not related to this PR.

Thank you@louismariegaborit and@Spomky.