Closed bc-pi closed 8 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.
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.
On the other hand, is implementing PKCE in the client sufficiently difficult that it's worth not passing it to the challenge endpoint.
We discussed this today and came up with the following solution:
redirect_to_web
request_uri
parameter to error response section (like PAR)request_uri
if the original authorization request contained PKCE code challengeI updated this so that the option of the PKCE shortcut for the redirect to web is available. This should all be possible now.
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.