I wouldn't regard JWT tokens to be part of OIDC, but rather a special type of Bearer token. Notably there is RFC7523, which specifies how to use JWTs for token exchange and client authentication within plain OAuth2, but I imagine there could be other use cases even.

As such an example use case that I know of: in the educational tech standards world, the IMSGlobal standards organization is proposing the use of JWTs as a way to carry signed messages from system to system within the Learning Tools Interoperability (LTI) standard, apart from using them as assertions of identity within an OAuth2/OIDC style workflow.

I agree. Let's move this out of the openid package.

Ok, my suggestion is to start using a tree like:

│   ├── tokens
│   │   ├── bearer
│   │   │   ├── __init__.py
│   │   │   └── rfc6750
│   │   │       └── __init__.py
│   │   ├── __init__.py
│   │   ├── jwe
│   │   │   ├── __init__.py
│   │   │   └── rfc7516
│   │   │       └── __init__.py
│   │   ├── jws
│   │   │   ├── __init__.py
│   │   │   └── rfc7515
│   │   │       └── __init__.py
│   │   └── jwt
│   │       ├── __init__.py
│   │       ├── rfc7519
│   │       │   └── __init__.py
│   │       └── rfc7523
│   │           └── __init__.py

And this can be keep as sibling of oauth2 and openid folders.

ls oauthlib/

common.py  __init__.py  oauth1  oauth2  openid  signals.py  tokens  uri_validate.py  webfinger

Would you reckon we need jwe and jws in our codebase, or can we just depend on a JWT library for that?

We can use a external lib but common interface would be nice cause we need change that lib for any reason we don't break things.

But this can be handled in a next PR would like let this PR as is and discuss how and where to move JWT in a proceeding one.

We could split our tokens implementation into a different package later.

JWE seems not used in OpenID Connect. JWT requires JWS, JWA and maybe JWK.

Let's use #537 to talk about it. This PR will not include no changes like this.