[Openid-specs-ab] Issue #1164: insecure front-channel use of private_key_jwt client authentication (openid/connect)
roland at catalogix.se
Mon Apr 20 15:13:04 UTC 2020
> On 17 Apr 2020, at 23:48, Brian Campbell via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> New issue 1164: insecure front-channel use of private_key_jwt client authentication
> Brian Campbell:
> “At a minimum openid-connect-federation needs to acknowledge that it's misusing private\_key\_jwt and do something to mitigate the security problem.”
> Please see [https://github.com/oauthstuff/draft-oauth-par/issues/41](https://github.com/oauthstuff/draft-oauth-par/issues/41) but particularly the comments at [https://github.com/oauthstuff/draft-oauth-par/issues/41#issuecomment-615081283](https://github.com/oauthstuff/draft-oauth-par/issues/41#issuecomment-615081283) and [https://github.com/oauthstuff/draft-oauth-par/issues/41#issuecomment-615475230](https://github.com/oauthstuff/draft-oauth-par/issues/41#issuecomment-615475230)
First, I’m glad we’re having this discussion.
Second, the specification says we want to use the private_key_jwt method of authentication not private_key_jwt
exactly as described in OIDC Core.
To distinguish our variant from the OIDC Core one in the specification we demand that aud is set to be the authorisation endpoint of the OP. We also ask for the iss and sub claims to be the entity ID of the RP. Furthermore we expect jti to be used to prevent reuse.
Now, if this isn’t enough let’s take a step back and look at the issue we’re trying to solve.
OIDC federation is built on dynamic discovery and registration. We want to avoid doing static registration since it scales very badly.
To begin with we had only one type of dynamic client registration, one that looks very much like what’s described in
in that the client sends a client registration request.
Now, when the OIDC federation draft was voted on to become an implementers draft (now soon 2 years ago) Andreas Solberg
came up with the idea to not have the client do an explicit client registration but to connect the registration to the authorization request in
such a way that the OP would ‘automatically’ do the registration when it got a request from an RP it had never seen before.
For this to work we needed a way to securely bind an authorization request to the RP metadata.
Looking at what was available in the OIDC arsenal, private_key_jwt jumped out. Using this method
we could see that the RP was in control of the private key of the key pair where the public would reside in the metadata.
This is the problem we need to solve. If we can’t use a client authentication method like the one private_key_jwt represents
what other alternatives are there ?
I’ve been pointed to one alternative and that is using pushed authorization with MTLS.
To me it seems like that could work though it adds another layer of complexity.
Scratch a pessimist and you find often a defender of privilege. -William Beveridge, economist and reformer (5 Mar 1879-1963)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab