Only partially correct. I think the earliest drafts of OpenID Connect were completely agnostic of JWT, and so is OAuth 2.0, but the final Open ID Connect Core spec is tightly coupled to the JWT standard in multiple places.

The first and most important coupling point is the ID Token. There are three types of tokens issued by Open ID Connect: Access Tokens and Refresh tokens are opaque, just as in OAuth 2. ID Tokens, on the other hand, most follow a more-or-less well-defined JWT format (as much as JWT can be well-defined - it is a somewhat wild west of a standard).

The rest of the places you could use JWT are in the spec, but I admit I've never seen them in the wild (and I would probably avoid them like the plague if I was trying to implement a _secure_ subset of an OpenID Connect IdP):

1. JWT request signing (and even encryption!) 2. JWT for signing and encrypting any JSON response 3. JWT for client authentication 4. JWT for aggregated claims

And I may have missed more things.

If you want to implement Open ID Connect without being crazy, forget about all of these and only use/implement the Auth Code flow with a client secret. You should still verify the ID Token according to the spec, but if you fail to verify it's no longer an issue, since this is a value you get directly from the the Authorization Server on an authenticated TLS channel (the same channel you'd trust for getting the ID Token signing keys).