Re: feedback on FedCM from BlinkOn

Hey Dan --

Now it's my turn to apologize for such a tardy reply... holidays and all. :)

> First off, thank you very much for sending this along, the feedback is greatly appreciated (and apologies for my slow response).

First of all, my initial email was under an incorrect assumption, so let me clarify that briefly:

I assumed the FedCM spec/effort was targeting the bounce tracking scenarios, and not just the 3rd party cookies in iframes. So, perhaps you can re-read all of my feedback in that light and that might change your mental processing on what I said (and might make many of my comments moot, at least for the current spec work).

Since I sent my original email, I finally had the time to go over the current spec work and the other various supporting documents (readmes, primers, etc). I guess my initial reaction is what's being done here is not really trying to solve any problem I have today, and instead is a brand new authentication spec with different and farther reaching goals than the current SSO specs. Given that, it seems like apples and oranges to try to say that the goal of FedCM is to preserve the protocol flows that exist today. I'm not sure where or why I got the impression that that was the goal, but it just doesn't seem to be the case. FedCm is a brand new, alternative SSO mechanism.


Getting into the mechanics, it seems to me that FedCM is trying to substitute for the scenario where an app would first try to use an iframe to test is a user has an authN session, and then silently piggy back onto that SSO session. I just don't have many customers who do it that way. They use the main top level window redirect to the IdP as the most common approach.


Having said all of that, given that the next phase of FedCM (from my understanding) is the tackle the bounce tracking scenario, then I'd re-iterate all my the concerns in my original email again.

> When you say there are hundreds of customers with their own IDPs, does this mean the customer has an IDP installed on-premises that the customer upgrades and runs? Or is it a SaaS solution where they configure a solution run by your company? Or is it a mix of both?

Yes, I have hundreds of customers that run their own OIDC/OAuth token server. These customers span industries (healthcare, financial, retail, biotech, government, etc), and they are logically hosting it themselves. Some even do redistribution of their product on-prem to their customers, which embeds and brings along the token server as part of their software suite.

As for the users of these systems, they are usually customers of these companies, but could also be employees, business partners, etc. These various users' credentials could be at the token server/IdP they have setup, or the users' credentials could at a federated IdP (e.g. AAD for employees, or Ping for a business partner's users), or it could be a mix of the two when used as a federation gateway architecture.

Any other vendor of IdP software that allows the customer to do their own hosting (non-SaaS offerings) is pretty much in the same boat. I think I mentioned these before, but I think Gluu, Ping, ForgeRock, WSO2, and others all fall into this category. And then of course there are all the companies that have implemented their own home-grown OAuth token servers (which I encounter far more often than I'd like). So I'd wager that puts the number of token servers out there into the thousands, if not tens of thousands.

> We started with the implicit flow returning id_tokens as that was the initial starting point we knew was broken (something like a single page application needing access without top-level redirection).

Not sure why that's the first use case, as a SPA with only an id_token alone is a pretty useless app. For that SPA to be useful, it needs an access token to use to invoke backend APIs.

Also, what about pure server-rendered apps? From what I could tell (and I might be missing something) FedCM does nothing to prove the user's identity to a backend. Perhaps those types of apps are not the target audience, given that it seems you're focusing on replacing the iframe techniques. So yea, maybe those are out of scope?

> We're investigating how this looks when you return access_tokens and if we need to also do refresh_tokens and what that looks like.

And using refresh tokens in the browser is dubious (and others on this list would likely want to strangle me for making such a claim :)). But anyway, let's just say that's not always an option for many app/API architectures. Many of our customers have blanket mandates from the CSO that no tokens will be allowed in the browser at all. 

> Clearing the cookies on browser close means a user session never survives a browser restart which is not the expected behaviour many users have at this point.

Yea, not sure if I agree with that (at least not as a default behavior). I always felt a user should be in control of that and opt-in site-by-site when they check the "keep me logged in" checkbox on each login page they want this behavior for. I can't tell you the number of times I've had issues with Chrome sending cookies that should have expired a long time ago (or should not have been persistent) because it ignored the Set-Cookie settings because the user enabled the "reload all state" feature. But you're in the browser business and I am not, so I digress.

> The option to customize the login UI is something that has come up previously but we have not had time to investigate at this point.
> Do you mean new user registration on the IDP side or on the website?
> All of these cases sound like the user is logged out of the IDP

Again, given my misunderstanding of the scope, perhaps these are moot for the current version of FedCM. But once you start to break bounce tracking then these are all important topics.

Thanks.

-Brock