We like to think about our OIDC implemetation as of issues-free one :) I also believe some of our customers have run security tests of their own, reporting issues to us so we could fix it. But we can't guarantee there are no more left undiscovered, only perhaps that there won't be any easy to find ones. So you may need to possess very indepth understanding of OIDC to find out those. Not sure whether this meets your expectations. In any case, we will be very grateful for your reports if you'll discover something serious.

Thank you for your answer but maybe I was not clear enough or you misread it. My goal is to MAKE it vulnerable so some people that are introduced to vulnerabilities in the authorization/authentication "sector" to be able to see them live. I will not be looking for vulnerabilities in the gluu server. So do you believe that introducing vulnerabilities in the code of gluu server would be feasible or it would be better for my purpose to head to a simpler implementation?

>So do you believe that introducing vulnerabilities in the code of gluu server would be feasible or it would be better for my purpose to head to a simpler implementation? All Gluu projects are open-source projects, and most of them are written in Java. Assuming you possess coding skills and ready to invest your time in reading source code to figure out how to make it vulnerable, I don't see why it's not possible (still assumes you are very good at stack of technologies used by Gluu Server and have good understanding of OIDC specs, to be able to break it enough to be vulnerable, but not completely unusable). Just keep in mind you'll have to [setup development environment](https://gluu.org/docs/ce/3.1.6/developer-guide/oxtrust-eclipse/) as you'll need to compile your Java binaries from sources after the changes are done.

Ok thank you very much for your answers. I will spend some time to see the code more thoroughly