search

aaronpk / oauth-first-party-apps

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

Always require PKCE due to possibility of fallback to web redirect flow #11

Closed gffletch closed 10 months ago

gffletch commented 1 year ago

I think we will want to require all native apps to implement PKCE at the native endpoint even though it's not really needed for full native experiences. However, if the AS determines the client needs to fallback to the web based redirect flow, it would be good if all the PKCE parameters are in place for the authorization. The fallback is really a continuation of the current authorization (not a new one) and hence it would be good for the AS to provide a redirect URI that continues the authentication "session" and hence the final call for tokens needs to be protected by PKCE.

PieterKas commented 1 year ago

Do we need the same for DPoP if you need Authorization Code binding capabilities (may need that even if you don't go to web).

aaronpk commented 1 year ago

If we go with PAR request URI option (#16) then we need the client to create the PKCE code challenge.

The DPoP question will be covered by the new DPoP section #8

PieterKas commented 1 year ago

Aaron and I discussed this and concluded it may be a good topic for the IETF 117 meeting.

aaronpk commented 10 months ago

I think this is not needed because the client can add the PKCE code challenge the first time the client pops out to the browser.