Hi,

I'm reading up on Signed and Encrypted ID Token Support, but I currently can't imagine a case where this is useful.

Looking at a Confidential Authorization Code Flow, how does it make sense to add another layer of encryption to a back-channel (Server-to-Server) which would supposedly be encrypted already? Or is this feature just for edge-cases where you can't trust the back-channel?

Alternatively, looking at a Public Authorization Code Flow (for example in a Mobile App), it wouldn't make a lot of sense to add Encrypted ID Tokens here either, as the clients private key would need to be baked into the app in plain text.

Am I wrong in my assumption that it doesn't make sense too much sense for Authorization Code Flows?
Is there a valid use-case for other grant types?

Also, from inspecting the network traffic of an unencrypted (!) confidential Authorization Code OpenID Connect Auth Flow, the access_token contains the same data as the id_token, namely the data I set in Clients Scopes -> Assigned Default Client Scopes.

I haven't had a chance to try it, but if I were to enable "Signed and Encrypted ID Token Support" now, would it also encrypt the data in the access_token?

Thanks!