How are we handling external IdPs?

[esgoodman]

The problem

We integrate Google OAuth as a convenience for GSA users who are likely already signed into Google. This is handy, but ends up complicating interactions.

Where do external IdPs fit in the sign-in flow?

Midas uses LinkedIn as an IdP independent of MyUSA. This means that users first hit a choice between MyUSA and LinkedIn, then (if they pick MyUSA) a choice between Google OAuth and using an email link.

People understandably can find this confusing. Why aren't the LinkedIn and Google choices presented on the same screen?

UX consequences

However, how OAuth transfers data from RP to IdP means that picking LinkedIn (for example) vs Google (for example) have very different consequences for what the IdP knows about user activities. Clicking the LinkedIn button means that LinkedIn will know what website the user is on (as per @yozlet). Clicking the Google button means that Google will only know that the user has signed into MyUSA. MyUSA does not pass information about Midas back to Google.

Decision points

There are three options that I see right now.

1. Dropping Google as an IdP for MyUSA, so that any 3rd party IdPs are at the discretion of the partner
2. Offering a limited selection of IdPs from which the partner can choose 2-3, to be used as alternatives to email access link sign in
3. Keeping the status quo, in which a partner can integrate a 3rd party IdP but MyUSA only offers Google as an alternative

[yozlet]

I favour option 1 (no external IdPs, leave to RP) because

• IIRC, research indicated that users weren't very comfy with the Google association - is that right?
• it reduces implementation complexity (and I will usually be in favour of things that do that)

But user comfort & convenience is paramount here. Having Google does make it much faster to sign in if you already have a Google session (which many users do).

[esgoodman]

I think you're right. It muddies our explanation of what MyUSA does if it is both a provider and consumer. And it adds another click to the process. The only reason Google is in there is for our own convenience, right? Because GSA has a contract with Google for services so we're all often signed into Google. But that's not going to be the case for people outside of GSA, necessarily. If a partner app really needs an external IdP, it can implement a page like Hub's or a modal like Midas' in which the MyUSA button lives next to the Google or LinkedIn or whatever button. Then there's a clear choice up front, instead of a choice distributed across two different screens.

[mkhandekar]

However, how OAuth transfers data from RP to IdP means that picking LinkedIn (for example) vs Google (for example) have very different consequences for what the IdP knows about user activities. Clicking the LinkedIn button means that LinkedIn will know what website the user is on (as per @yozlet). Clicking the Google button means that Google will only know that the user has signed into MyUSA. MyUSA does not pass information about Midas back to Google.

Clarification: is this how IdP's work / worked / will work in terms of what data gets shared back to the IdP?

---

If a partner app really needs an external IdP, it can implement a page like Hub's or a modal like Midas' in which the MyUSA button lives next to the Google or LinkedIn or whatever button. Then there's a clear choice up front, instead of a choice distributed across two different screens.

Clarification: If a partner app chooses to go with just MyUSA and no external IdP's, the user flow would be like this always (correct?):

Partner site > MyUSA > Sign up/Log in with Email (remember me for 2 weeks as an option) > check email for access link > set permissions > back to Partner Site

---

My vote is for MyUSA to be in a place between options 1 and 2 — to default to no IdP's, but to provide a limited selection of IdPs to choose from if they need it, because:

• Visitors did not want to link a government persona of themselves with their social (google) persona.
• Providing some IdP options (and each option's benefits) for partner sites to choose from seems beneficial because then we have some control over that user experience. I wouldn't want our partners to have to make the decision and design the implementation of the IdP themselves.

[kategarklavs]

Having reviewed this conversation (and based on conversations I've previously had with @esgoodman), I'm also in favor of options 1 and 2 (or some combination thereof).

[yozlet]

@mkhandekar Can you clarify what "all user data" means in the diagram? In the top examples (blue arrows) external IdPs won't, by default, receive any of the data the user submits to the app unless the app explicitly pushes it out. However, the IdP will have an explicit association between the user and the app (which is not nearly as bad)

[esgoodman]

@yozlet I think @mkhandekar means what you said.

[mkhandekar]

@yozlet I meant what you said! The (top) open blue lines mean that data is passed on when app pushes it out, and the (bottom) green closed lines mean that the data transfer ends with myusa and is not shared with any other parties.

Thanks @esgoodman :)

[esgoodman]

So after talking to Sarah and Raphy, it sounds like both Communicart and Midas really want to keep on using Google Auth. @mkhandekar's proposal seems like the right direction, since it allows gov't employees who already use Google for work to keep using it with MyUSA (thereby greatly simplifying their sign on) and doesn't force integrators to undo what they've already done.

I do not know how complex it is to offer a limited selection of IdPs from which the partner can choose 2-3, to be used as alternatives to email access link sign in.

However, what we can do right now is make the Google sign-in on this screen

less prominent so that it doesn't seem like the only choice. We can also give integrators a set of assets and a styleguide so that we are more likely to end up with a consistent initial sign-in feel.

[mkhandekar]

Mailchimp article shared by Yoz: "Social buttons aren't worth it"

When is it appropriate or inappropriate to use social login buttons? Sometimes it makes a lot of sense, and other times it’s just not worth the trade-offs. But don’t use them because they’re on every other popular app. Use them because they serve a purpose for your business and your users.

[esgoodman]

Preliminary decision: We keep Google OAuth available (but de-emphasized) for integrators with likely users who are federal employees at agencies who already have a contract with Google. That makes Google sign-in available to the people who might expect it and find it convenient. For the public, we remove Google OAuth because they have no prior relationship established with Google as a government vendor and so it jarringly violates their expectations. We can make special arrangements as we go with integrators who really need another 3rd party IdP...but not until someone really needs it. Let's close this!