Hi, I have a question related to the id_token mutator . The documentation says > This mutator takes the authentication information (such as subject) and transforms it to a signed JSON Web Token, and more specifically to an OpenID Connect ID Token. In the example, it show a Basic Authorization request, with the session information converted into a JWT and propagated in the

authorization

header. Is there a reason this is specifically an OpenId Connect ID token, or does it just match that convention? The example isn't really using an OIDC flow. From usage, it seems like it's an internal token intended as something like a session token, to propagate authentication information to a downstream service. If I remember correctly, the

id_token

is intended for use by the client rather than being propagated downstream. Sorry if this is a philosophical point, I'm just trying to understand the intend usage to I don't use this for the wrong reasons 😅 The idea of swapping an external authentication (the session info) for an internal represenation (a JWT) is what I'm looking for, so the way it works seems to fit, but the mention of OIDC has confused me a little bit.

it's just a format in this case, you're right there is no OIDC flow happening

Ok, great, thanks. I guess there's no "standard" for internal token formats, but the OIDC one is probably flexible enough for this purpose.

There is a standard for a JWT token format. And that is defined by OIDC to be mandatory for the id token. There are also other formats defined, like a MAC token, which can be used for the other token types defined by OAuth2. There is also an access token JWT profile rfc if JWT is used as format for the access token.

Sorry, what I meant was that there's no standard for the claims that represent an "internal" token for a first-party system, which makes sense because identity will look different in different systems. Of course you can use jwt for that, and there are many standards defined for OAuth/OIDC. What I was really asking if this token was acting as as OIDC

id_token

, which it is not. It just matching the claim format for an OIDC id_token, but without the same semantics and restrictions (e.g. only intended for the client, must match

aud

claim, etc).

The JWT issued by Oathkeeper just follows the JWT RFC and includes by default just the minimal useful set of claims defined here. Everything else (all other claims and further structure) is let open to the user/integrator of oathkeeper. That allows you basically defining an own profile for your particular application, where you can define your own semantics and restrictions. And this is great as there will never be a definition which would fit all use cases.