-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider: Unblock federated logout by making storage access allowance symmetric #82
Comments
Just as an extra idea that we are starting to float around, here is how we are thinking federated logout could work within WebID: The current belief is that, if the browser can observe the "login to rp.example with idp.example", it should allow So, the question then becomes, how can a browser observe the "login to rp.example with idp.example" with confidence (i.e. in a way that cannot be abused by an adversary)? There are two variations here, but just to give you a sense, one of them is to use the WebID mediation flow and the oauth heuristics:
When a user wants to logout:
There is a different variation where we are exploring using a generic "permission prompt" as opposed to an "account chooser", but otherwise that's the gist of how we are considering going about this in WebID. This is a bit social-networky, but here is what the UI for the account chooser is starting to look like (in this case, it is a single account): |
@samuelgoto in steps 4-5, how does the IDP know it should return the list of logged in users? I'm not sure it's a good idea to have an open API that can be called from any browser (where the IDP has been used in the past) that returns the list of logged in users. Also what if no user is logged in but there is a list of users who have logged in from that browser in the past. This list is often presented in an IDP formulated "account chooser". Does the browser need to know those identities as well? Also, why does the browser need to store which identity the user selected from the account chooser? In the logout flow the IDP isn't being required to identify the user via the same identifier? In the context of OpenID Connect, the value that matters is the session id. I think I like the idea of the "generic permission" prompt as long as that permission is remembered for the rp:idp pair so that user doesn't need to give permission for every identity flow. I think for logout 3p cookies to flow, the browser just needs to know that "a user" has logged in to this rp:idp pair in this browser. |
@gffletch The list of accounts to be populated in the account selector would be up to the IdP, and depend on the cookies that it has previously set on the client. If there is no signed-in account, or if the user wants to use an account that isn't in the list, then there would have to be a fallback where an IdP sign-in page would have to be loaded, possibly in a modal window. I don't know if it is a problem for an IdP to expose such an endpoint, since it only returns information to a request with valid cookies. If somebody with ill intent has a user's cookies then I don't know that this makes the situation any worse than it already is. One concern with linking this with the mediation variation of WebID is that it becomes a hard requirement for any IdP that wants session management capabilities to convert to using that flow, which surrenders much of the sign-in experience to the browser, and could potentially mean high variance in UX between different browsers. The ability to get session management privileges based on a permission has much less of that problem. |
On
And
The "generic permission" prompt [1] would work equally well (from a privacy perspective), but we ran into UX difficulties that lead us to think it is worth exploring a second option, "a mediated account chooser". There is still much to be learned and gathered from implementation experience, but the UX difficulties were around "branding" and "RP and IDP names" in a privacy preserving fashion (with the alternative of showing just domain names possibly cumbersome). I don't think these are problems that are impossible to solve, but I think there is a lot of details here to be uncovered. [1] To be concrete: "generic permission" is probably the wrong terminology (i don't think it was your intent), but a browser needs to observe something very specific: a login. so, i'll use going forward "a static login to RP with IDP" prompt rather than a "generic permission" prompt. I hope this matches your intent too. So, no disagreement that "generic permission" could work too, and so far I'm of the position that both options should be offered and allowed to be picked by the IDP. |
An issue with unblocking federated auth in the absence of 3p cookies using the storage access API is that it is a one-way trust. The permission grants idp.example access to its session cookies on rp.example, allowing auth to occur. However, it does not grant access to rp.example session state while on idp.example.
Federated logout is specified today as a visit to a well-known logout URL on idp.example, which then opens iframes of pre-provided logout URLs on each RP. With the removal of 3p cookies, these iframes (e.g. to rp.example/logout?sid=foo) are opened without session artifacts. For stateless RPs, they lose the ability to reliably signout the user, creating a security issue.
Single page app RPs today perform signout by either deleting their session cookies when receiving an iframe-based signout request, or dropping a tombstone cookie that tells them to delete their session cookies on next use (for cookies with SameSite Lax). Neither of these approaches work any longer.
I propose a solution here, which is that if idp.example has received storage access when embedded in rp.example, rp.example should receive storage access when embedded on idp.example.
This has two known drawbacks:
The text was updated successfully, but these errors were encountered: