Short IdP cookie lifetimes

[yoavweiss]

As part of an effort to reduce the blast radius of cookie theft, a recent proposal called Device Bound Session Credentials aims to enable service providers to have very short session cookie lifetimes, and revalidate them using DBSC without bothering the user (at a cost of a potentially-preflighted round trip).

That’s great as short-lived cookies are less-exploitable cookies, e.g. in cases the user has local malware on their machine.

However, AFAICT, that doesn’t work well for FedCM. If the IDP’s session cookie has expired, the only option to renew the cookie is through a user-visible modal, which would create a sub-optimal user experience and add a lot of friction.

Would it be possible to create an IDP cookie renewal flow that doesn’t require a user-facing modal?
From a security perspective, that seems fine, as cookie expiration times are at the discretion of the IDP, so performing renewals without a modal doesn’t seem to degrade the user’s security, and will enable short-lived cookies which would augment it. We will of course need to distinguish cookie expiration from e.g. server-side cookie invalidation.

Thoughts?

/cc @gioele-antoci

[wparad]

If the IdP cookie has expired what's the alternative to asking the user to reauth if the website requires it?

[yoavweiss]

The alternative is to run a DBSC negotiation and allow the IdP to renew its cookie without a top-level navigation.

[johannhof]

Not sure I fully grok this issue. FedCM mediates a token that is requested from the IdP in a credentialed fetch https://fedidcg.github.io/FedCM/#identity-assertion-endpoint. Presumably such a request would be able to perform a DBSC negotiation without the need for any specific FedCM-level mechanics?

[samuelgoto]

Presumably such a request would be able to perform a DBSC negotiation without the need for any specific FedCM-level mechanics

That's partially my intuition too: DBSC does, indeed, make cookies shorter-lived, but it also refreshes them periodically, such that there are always valid cookies in the jar.

So, as far as I understand DBSC, its usage in conjunction with FedCM should be orthogonal: one shouldn't step on the other, I believe.

@yoavweiss does that match your intuition too?

[yoavweiss]

I may have misunderstood the request flow.

I guess that if DBSC would properly delay requests going to the identity assertion endpoint with bound and expired cookies, this can work without bugging the user.

[samuelgoto]

delay requests going to the identity assertion endpoint

By the time we get to the id_assertion_endpoint, FedCM has already queried the accounts_endpoint, which is a credentialed fetch.

this can work without bugging the user.

Yeah, I believe that's the case, but it is worth trying it out and gathering implementation confidence.

[cbiesinger]

https://github.com/WICG/dbsc?tab=readme-ov-file#high-level-overview mentions that the request gets deferred while the DBSC is refreshed, so I am not sure there's anything to do in FedCM, especially spec-wise

[yoavweiss]

Yeah, closing for now. Thanks for clarifying!!