I'm not part of the Keycloak team, but I wanted to mention that I’m currently working on an implementation of ML-DSA (CRYSTALS-Dilithium) and plan to contribute it to Keycloak once it reaches a stable stage.

There's no real challenge in implementing a PQC signature mechanism in Keycloak; that's pretty easy we just need a key provider and a signature provider. One challenge is representing the keys in the JWK endpoint, as the standards are not ready for how to do that. That means the keys have to be shared in a non-standard way, for example using PEM files.

Another tricky part is that you don't want to use any of the PQC signature algorithms on their own at this point, as it is still unclear how secure they are and interoperability is most likely going to be a pain (not all libs will supported them, and the whole JWK issue). That basically means the recommendation right now is to use hybrid signatures, but that's not something JWS supports (and also would increase both the size and cost of signing).

There's also the fact that tokens are short-lived; hence it is less of a priority to find a solution since there are still years until quantum computers are available. That doesn't mean do nothing, and we are paying attention to what is happening in the specs and elsewhere.

Since you mention encryption in the title; symmetric encryption is relatively unaffected by and recommendation is to continue using AES for example. The problem with symmetric encryption is the key exchange part, for example in TLS.

What is a higher priority is TLS due to store now decrypt later attacks; for example someone could store login request to Keycloak now, then decrypt user passwords years from now.

In terms of algorithms, all are readily available to Keycloak today, here's some more details:

Algorithm       Size         Size (url)   Key Size     Time (ms)   
ES256           71           96           182          0.55        
ES384           104          140          220          2.02        
ES512           139          188          274          2.83        
FALCON-512      655          876          1314         1.03        
FALCON-1024     1275         1700         2546         1.38        
ML-DSA-44       2420         3228         1890         0.96        
ML-DSA-65       3309         4412         2770         0.64        
ML-DSA-87       4627         6172         3652         0.35        
RS256           256          344          460          1.02        
RS384           384          512          636          2.84        
RS512           512          684          814          5.56        
SLH-DSA-128s    7856         10476        126          794.86      
SLH-DSA-128f    17088        22784        126          35.39 

ML-DSA is fast enough, but signatures are big (6172 bytes url encoded), it's also considered well understood from a security perspective. So the problem here is signature sizes.

SLH-DSA is extremely slow and signatures are enormous. This is considered more a backup option if all other signatures are considered insecure.

Falcon is fast and signatures are not that big (872 bytes url encoded). Problem with this one is that the security properties of it is less well understood.