I’m wondering if I really need OpenID Connect to provide authentication on top of OAuth2. It seems to me if I generate JWTs (JWE) as my access token and I store user claims, roles/permissions, etc. in the access token, then the OpenID Connect's id token isn't needed. Resource servers can validate the access token on each request. Alternatively, I could keep the access token small and just have it store a session id and populate that session with claims/roles/permission. Also I could put an expiration value in session and support sliding expiration, etc. and not even deal with refresh tokens. Am I missing what OpenID Connect is really about?
Update
I just realized I need to clarify my question a bit. If I built a site where I allow users to login via Google, I see how OpenID Connect is necessary. I'm allowing someone access to my site based on some OAuth authorization flow which doesn't prove authentication happened. But if I'm building a bunch of services and I just want to issue tokens to access these service resources, isn't OAuth enough? And if I wanted these tokens to contain roles/claims so I can make authorization decisions in my services, isn't a JWT containing roles/claims enough? If feels like OpenID Connect wouldn't be necessary in this case.
By requiring that the access token is a JWT, agreeing on the user claims that go in to the JWT, putting expiration/issuance timestamps in there and making sure that you cryptographically verify the issuer of the token you're actually doing the very same thing that OpenID Connect is doing: "profiling" OAuth 2.0 in such a way that it can provide user authentication/identity information.
Update:
But if you don't need user authentication semantics you can stick with OAuth 2.0. You may use a JWT as an access token so the Resource Server (the API) can verify and inspect the access token and find out on whose behalf the client is acting. But just be aware that the possession of that token does not mean that the user is present (and authenticated) at that time.