@VinodAnandan My main interest in asking the question is that I'm working on OpenID Connect standard openid-connect-key-binding and I was interested if there were any existing deployments doing this. The hello OP is the only OP doing this that I am aware of.

Could you please help clarify and expand on the threat scenarios you’re considering?

Consider the common case of a public OIDC client consisting of javascript running in a web browser and a backend running on a server. The javascript is granted the ID Token and the javascript sends it to the backend to authenticate the identity of the user. The ID Token can leaked to an attacker in three places:

1. The javascript running in the web browser could be compromised by an XSS leaking the ID Token,
2. The backend server that receives the ID Token from the web browser could be compromised or leak the ID Token in a log file
3. and finally the ID Token could be leaked or stolen in transit. For instance load balancers terminate TLS sessions, so the load balancer and an intermediate server between the load balancer and backend could be compromised and leak the ID Token.

Instead if a ID Token is key bound, the web browser can securely store the key and authenticate via DPoP.

There is also a lot of use of ID Tokens in SSH, but a bearer token presents the use of one SSH server replaying an ID Token to another SSH server (both SSH servers are the same client/same RP). One of my projects, OPKSSH, uses the nonce in ID Tokens to do something like key binding to avoid this attack: https://github.com/openpubkey/opkssh

Why use a bearer token when you can use DPoP and remove entire classes of attacks?

I’m not an SME in this area, so please excuse any inaccuracies or misunderstandings in advance.

From my limited understanding, SPAs are expected to use the access_token when calling backend APIs, while the ID_token is primarily intended for use by the SPA itself to obtain identity & profile information from Keycloak ?

That said, I do agree that, in general, it’s beneficial to protect the ID_token with DPoP in any scenario where the ID token is used as described in the second use case, or in any other situation where the client/RP transmits it.

I’m not fully aware of the complexities or potential challenges involved, but my assumption is that the additional overhead for implementation should be minimal. Maybe our experts (@Captain-P-Goldfish @dteleguin @tnorimat @mposolda @thomasdarimont ) perspective would be valuable here.