User Story: Federated Login Service with IdP Federation

[achimschloss]

User story

A federated login service allows users to choose between multiple IDPs to select from based on their account/username preference to sign in/up to a service. A concrete example would be multiple e-mail providers (IDPs) allowing their respective users to sign-up/in to others services via one federated login service.

Flow from service (user wants to sign in/up to):

As a user I'm starting a sign-up/in flow into a service using that federated login service. I'm presented with a choice (by the federated login service) with which username/account to continue the flow. I'm providing my preferred account and the federated login service routes me to the respective IDP which runs me through a flow (authn/authz) resulting being signed into the service (i.e. returning assertions about my identity to the service as authorized for that specific service by me).

As a user im expecting that my provided username/account choice is processed for the purpose of signing in and that the assertions about my identity are passed back from the IDP to the service where I initially started the flow.

Context of the story

This story applies to any standard consumer authentication flow, both web and mobile.

Should this be considered sanctioned or unsanctioned tracking?

Sanctioned tracking

Explicit list of parties involved

• User
• Service user is signing in/up to
• Federated login service (integrated with the service)
• Identity Provider(s) being federated (integrated with Federated login service)
• Browser / mobile operating system

Complicating characteristics

• Assertions about user are passed from IDP via the federated login service to service the user is logging into
• Federated login service and IDPs exist on different eTLDs for security/privacy reasons

Additional information

• Federated login service / IDPs operate under aligned privacy/security policies

[hlflanagan]

Would this kind of scenario require 3p cookies? Such as when the federated login service presents options to the user - would that be the same set of options, or would it pull past choices from a cookie set by the service the user is signing in to?

[achimschloss]

The federated login service would pull past choices/status from cookie(s), but this is not a 3rd party integration flow. The federated login service would pull that information after a top level navigation to the federated login service itself from the service the user wants to sign in/up to. In that sense it does not deviate from a "classical" flow (user clicks button and is redirected).

This is focussed about passing information leveraging top level navigation with an additional complication of an additional (user facing) party is involved. I guess technically you could think of it like any authn/authz scenario which runs via more than one eTLD using redirects (I guess there a more of those besides this one) from a browsers perspective. So the main point is that these flows can be more complex.

3p party depend user stories could apply in this setting too, i.e. personalisation/login options as described by the Google team based on prior interactions with the federation service (so it needs access to the user "state"/prior choices), but those might no deviate too much here.

[bmayd]

Per my comment on the call: the federated login service could mediate all communications between the service and the IDP or it could just facilitate the discovery of the IDP by the service, with IDP subsequently communicating directly with the service.

[achimschloss]

Yes - would be a different user story, something like automated IDP discovery / smart login buttons. There are implementations like this in the market, that "wrap" 1000s of IDPs

[hlflanagan]

Discussed during 22 October 2021 fedidcg call