search

openid / federation

7 stars 4 forks source link

Revisit private_key_jwt client auth at the federation endpoints ("aud" claim) #98

Open vdzhuvinov opened 1 week ago

vdzhuvinov commented 1 week ago

Several months back we specced the possibility for callers to authenticate at federation endpoints with private_key_jwt.

8.8 Client Authentication at Federation Endpoints https://openid.net/specs/openid-federation-1_0.html#section-8.8

In view of the recent sec review, two points to consider:

  1. Change the aud from the endpoint URL to the Entity ID?
  2. Should JWT responses to authenticated requests set the aud? Reasons why one may want to "aud" the response? Pros / cons? Requiring the aud to be set will largely prevent the issuing Entity from being able to cache the minted JWTs.
SECtim commented 1 week ago

My two cents on point 1: From a security point of view, either should be fine, as long as "the endpoint URL" means "the exact URL to which this specific client assertion is sent" (as opposed to "one of the multiple published Federation endpoints").

However, if #94 results in "RP MUST use OP's entity ID as audience", then it might make sense to align the authentication at Federation endpoints with that.

vdzhuvinov commented 1 week ago

Thanks Tim for your input here. I'd change to Entity ID for the aud value. It should result in simpler and safer code, both for clients and the Federation entity. I checked our code and for this check when the aud is an endpoint it constructs the URL dynamically. With the Endpoint URL there's a single final var to deal with.

selfissued commented 2 days ago

I don't think it makes sense to put an audience in Entity Configurations, because they are used by multiple parties.