Not clear why AS needs to support signed+encrypted ID Token

There are two reasons for asking for it.

1) To cope with the internal attacker after TLS is terminated; 2) To cope with the man-in-the-browser when ID Token is returned in the front channel.

In many cases, TLS are terminated at gateways. Since about 50% of attacks comes from the internal network, non-TLS traffic within the LAN is at risk of being eavesdropped. Encryption helps with these cases.

ID Token in the front channel works as the detached signature for the authorization response, so it is indispensable for the protection of the authorization response payload, but it is not protected by TLS within the browser so the eavesdropper in the browser can actually see it if it is not encrypted.

Do we care about these threats? Since the token is signed anyway, the risk is primarily a passive one thus it should not be too high even if we did not encrypt after all.

Perhaps we should change "shall" to "should" so that it will be:

should support signed and encrypted ID Tokens;

Comments (6)