aaronpk / oauth-first-party-apps

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

First Party Native Apps in Browsers #29

Closed PieterKas closed 10 months ago

PieterKas commented 12 months ago

A participant at OSW suggested they would consider using the native apps spec in the browser. That is contrary to our recommendations in the spec, but opening an issue here to keep track of it until we understand more about that use case.

gffletch commented 11 months ago

Interesting, in that "native controls" are limited within a browser. My big concern is how to have high trust it's a 1st party app. Communications could be protected with DPoP to some extent. Hmm...

gffletch commented 11 months ago

I think the biggest issue for me with browsers is that we don't have any equivalent to an "OS App attestation". If the browser was willing to assert that the JS app was loaded from a particular domain and provides some sort of attestation as to the code it received (hash of loaded JS)... then maybe. There just are the same controls within the browser environment that there are for mobile applications.

dteleguin commented 11 months ago

Hi, OSW participant here :) Our main use case is reauthenticating the user of the SPA (step-up, transaction confirmation etc.) without leaving the context of the application, providing native experience at the same time. When using redirect-based flow for the same, the live data stream from the application will be interrupted. This includes (but is not limited to):

Iframes and popups could do the trick, but there are (at least) two problems here:

aaronpk commented 10 months ago

We can expand the new SPA security considerations section to include: https://aaronpk.github.io/oauth-first-party-apps/draft-parecki-oauth-first-party-apps.html#name-single-page-applications