aaronpk / oauth-first-party-apps

https://datatracker.ietf.org/doc/html/draft-parecki-oauth-first-party-apps
Other
10 stars 8 forks source link

PAR response w/ request_uri and PKCE doesn't quite work #46

Closed bc-pi closed 5 months ago

bc-pi commented 9 months ago

PAR https://www.rfc-editor.org/rfc/rfc9126.html#section-4 in conjunction with JAR https://www.rfc-editor.org/rfc/rfc9101.html#section-6.3 and https://www.rfc-editor.org/rfc/rfc9101.html#section-5-9 defines things such that all the authz request parameters have to be in the original PAR request referenced by the request_uri. The AS only uses request_uri and client_id parameters from the request to the authorization endpoint.

So on a Redirect Response a client could start an authorization code flow with the request_uri received but PKCE parameters added at that point will be ignored by the AS.

All of which is a kind of awkward way of saying that https://www.ietf.org/archive/id/draft-parecki-oauth-first-party-apps-00.html#name-redirect-response doesn't quite work as written.

aaronpk commented 9 months ago

I think this is why we originally had a note to possibly add the PKCE code challenge to the initial request, even though it wouldn't do anything unless bounced out to the web. But it seems weird to require it on every request when most of them will not result in a redirect response.

I was trying to take a shortcut here but maybe the answer is to just return an error message and have the client start a new flow with whatever it wants (PAR, plain auth code) itself. We'd just need to add a new parameter to the request to carry the auth_session.

bc-pi commented 9 months ago

I think this is why we originally had a note to possibly add the PKCE code challenge to the initial request, even though it wouldn't do anything unless bounced out to the web. But it seems weird to require it on every request when most of them will not result in a redirect response.

Yeah, I had a similar thought but agree that it's weird. Especially since the redirect response will probably be the significantly more uncommon case.

I was trying to take a shortcut here but maybe the answer is to just return an error message and have the client start a new flow with whatever it wants (PAR, plain auth code) itself. We'd just need to add a new parameter to the request to carry the auth_session.

Probably but need to be careful about passing auth_session in the front channel where it's much more prone to leakage. That could be problematic if an auth_session value could be used by another party at the authz challenge endpoint to take over the session.

gffletch commented 8 months ago

On the other hand, is implementing PKCE in the client sufficiently difficult that it's worth not passing it to the challenge endpoint.

aaronpk commented 8 months ago

We discussed this today and came up with the following solution:

aaronpk commented 5 months ago

I updated this so that the option of the PKCE shortcut for the redirect to web is available. This should all be possible now.