[Openid-specs-ab] Issue #1164: insecure front-channel use of private_key_jwt client authentication (openid/connect)

Joseph Heenan joseph at authlete.com
Mon Apr 20 16:27:16 UTC 2020

Hi all,

> On 20 Apr 2020, at 16:13, Roland Hedberg via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> 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.

I can’t see any of those requirements mentioned when describing the authentication endpoint authentication at https://bitbucket.org/openid/connect/src/default/openid-connect-federation-1_0.xml#lines-2085 - is that mentioned somewhere else?

> 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 ?

A signed request object, passed by value, would achieve the same goal of showing control of the private key I think?

> 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.

I’m not sure why MTLS given the current federation draft doesn’t mention MTLS that I see?  But PAR (with an unsigned request object) with private_key_jwt (or MTLS) sounds like it’d solve the problem too.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20200420/3eec1d8a/attachment.html>

More information about the Openid-specs-ab mailing list