This is a translation of an article I wrote for our internal knowledge base at work, and that we later decided to publish (in French).
This art...
For further actions, you may consider blocking this person and/or reporting abuse
Very good and valid points! I would summarise this as: "JWT's can be used in a secure way, but can also be implemented in a totally incorrect way".
As in many technologies, the technology itself doesn't guarantee security, it is the implementation that matters.
Nice overview with many interesting things to consider.
I do disagree with you on this part however:
Here HTTPS only guarantees that the ID Token has been transmitted securely between the end user's user agent and the OpenID Connect client (website). You must still verify the JWT in order to confirm it was issued legitimately from your trusted identity provider. Omitting this introduces many major security risks.
Which flow are you talking about? With the authorization code flow (which you should use over anything else), the ID Token comes right from the IdP in the token response, so HTTPS guarantees both authenticity and integrity (and confidentiality).
If you're using an hybrid flow or implicit flow (but you shouldn't) then I agree you must validate the ID Token signature, as it comes from an insecure channel (redirect or possibly form post)
You are right with respect to the authorization code flow, and that is indeed the flow that should be used always. I checked the specifications and it even explicitly mentions that there is no need to verify the JWT signature. To be honest, I never really realized this.