search

WICG / dbsc

Other
296 stars 24 forks source link

Should this approach extend to native applications? #38

Closed NickBorgersOnLowSecurityNode closed 2 weeks ago

NickBorgersOnLowSecurityNode commented 5 months ago

This isn't necessarily the scope of the proposal and I don't know if it should be co-mingled, but I wonder what native apps will do. It's perhaps a different failure mode for native client tokens to be stolen because something like a malicious browser extension probably wouldn't be able to accomplish, but is another situation where session token theft can be a problem and device binding would help mitigate.

If considering attacks beyond a browser it really indicates the OS needing to provide an API for creating keys which userspace software can request operations with (sign/encrypt) but not directly access without elevated OS privileges. I'm not well-versed in the nuances of how this has been implemented.

I'm coming at this from the perspective of a Corpsec Engineer who struggles with consistent revocation of long-lived session tokens in SSO-integrated apps. This proposal doesn't address that problem, but I'm acutely aware of just how many forms sessions tokens take. On a mobile OS (iOS/Android) stealing the session tokens from another application likely implies a level of host compromise that only a TPM/Secure Enclave would mitigate, but on a desktop/laptop OS my impression is that userspace privileges could likely be used to harvest session tokens so device-binding would provide some value.

These thoughts came to reading responses to https://github.com/WICG/dbsc/issues/13

arnar commented 5 months ago

If your native apps use OAuth, it's well worth considering DPoP at least on the refresh token -> access token exchanges. In fact doing something similar* to that is what led us to DBSC.

(* Similar because it pre-dates DPoP, but in the end it's a simple JWT in the client_assertion on the /token endpoint.)

NickBorgersOnLowSecurityNode commented 5 months ago

An RFC to read (on DPoP), thank you.

I will subsequently :cry-in-corpsec: because I don't get to write/modify the code of any products I'm responsible for the security of.

kmonsen commented 2 weeks ago

We have discussed this for a while, and have decided for now DBSC will only be available in Browsers as apps can use similar things themselves. It will most likely be available for apps using webviews for Android, but most likely not for the apps only using the chromium network stack (AKA cronet).

NickBorgers commented 2 weeks ago

Not that I needed to, but I agree with leaving native apps out of DBSC's scope.

arianvp commented 2 weeks ago

One interesting piece of feedback that i have w.r.t to this is that Apple has something akin to DSBC https://developer.apple.com/documentation/devicecheck/validating-apps-that-connect-to-your-server for native apps which reuses the WebAuthn format for signstures.

For compatibility reasons it might be interesting to consider WebAuthn instead of jwt for the signatures.

Though honestly not a very strong opinion on this. It's just awkward that a modern website will have to have two slightly different signature schemes implemented in order to implement secure sessions. WebAuthn for log in and DSBC for session continuation.

It might be preferable to collapse this into just WebAuthn so there is less to implement for Relying Parties.

I think Apple made that choice deliberately as people who adopt passkeys in their apps for user auth might as well use the same code for adding device auth on top.