Add support for the "social" authorize to beginOAuth2()

[tomwayson]

In the Hub, and soon to be in Hub ready apps, we leverage the seemingly undocumented "social" authorize endpoint to go around the default login screen send users directly to the facebook/google provider sign in/up pages. For example, we first show this modal:

Clicking on the Facebook/Google buttons will open an OAuth popup that goes to /sharing/rest/oauth2/social/authorize?socialLoginProviderName=<google|facebook>&autoAccountCreateForSocial=true&width=800&height=500 along w/ the rest of the OAuth2Options like clientId and redirectUri. That route in turn redirects to the provider's own page:

I think once the user does their business over on the provider pages the rest of the flow is the same (the redirect uri is opened with token, state, expires_in, username etc).

I'm hoping this can be done fairly easily by to to extend OAuth2Options to have a path which defaults to /rest/oauth2/authorize but in this case would be overridden by /rest/oauth2/social/authorize along w/ additional props for socialLoginProviderName and autoAccountCreateForSocial (and maybe width and height?).

The relevant code that the Hub uses can be seen here:

https://github.com/ArcGIS/opendata-ui/blob/cfbcc8541de10ca67311375a59745e12c1cb5d3f/packages/opendata-ui/app/components/od-sign-in-modal/component.js#L62-L85

And then here:

https://github.com/Esri/torii-provider-arcgis/blob/8be3bdfe99647d1ac87f7b813553fb5968033b14/app/torii-providers/arcgis-oauth-bearer.js#L65-L162

Who's with me? ⚔️

[tomwayson]

I can confirm the above approach works by changing the following line n auth.umd.js in my node_modules:

        var url = portal + "/oauth2/authorize?client_id=" + clientId + "&response_type=token&expiration=" + duration + "&redirect_uri=" + encodeURIComponent(redirectUri) + "&state=" + state + "&locale=" + locale;

to:

        var path = _a.path || "/oauth2/authorize";
        var url = portal + path + "?client_id=" + clientId + "&response_type=token&expiration=" + duration + "&redirect_uri=" + encodeURIComponent(redirectUri) + "&state=" + state + "&locale=" + locale + "&socialLoginProviderName=" + _a.socialLoginProviderName + "&autoAccountCreateForSocial=" + _a.autoAccountCreateForSocial;

[jgravois]

I'm bussing down to San Diego today and in and out of meetings, but I'll definitely take a hard look at this.

[tomwayson]

out of meetings

better get some more meetings.

I can PR this real quick, main thing I need from you (& ideally @patrickarlt) is validation of the idea (👍).

[jgravois]

maybe we could even just autoconstruct the url to tack on social/ internally if the corresponding parameters are present?

[tomwayson]

I like that, I would base it on the existence of socialLoginProviderName

[patrickarlt]

@tomwayson this is a great idea. What about a provider option with 3 possible values arcgis, facebook, google that defaults to arcgis and we can build the URL from that. This only adds 1 option and is 100% backward compatible as opposed to adding 2 options path and socialLoginProviderName .

I don't really see a need for autoAccountCreateForSocial or width and height options. We could always add them later if someone asks but in the absence of real doc from the Online team it might be better to just copy their implementation.

[jgravois]

i think @patrickarlt's suggestion makes a lot of sense. i'll take a crack at implementing it.

[tomwayson]

Thanks guys!

I agree except for one thing: the Hub and Hub related apps already need autoAccountCreateForSocial, so I think we'll need to support that from the get go.

[patrickarlt]

@tomwayson out of curiosity what does autoAccountCreateForSocial do?

[tomwayson]

ordinarily they are requesting to join an org, and they have to wait for approval, but w/ this an account is automatically created and they join directly. I'm not sure if the org has to be configured to allow that - but this is the desired behavior for all Hub orgs.

Hmm... now that I describe what it does, it really does seem that we should set the default to false for this and add a parameter so the Hub and Hub apps can set it to true.

[patrickarlt]

@tomwayson I thought the social login stuff created a public account not an account tied to a specific org?

Looks like there is an org setting for this:

So here is my question. If I don't have an an AGOL account and I hit one of these sign in links and autoAccountCreateForSocial is true do I automatically get an account for the org that the client id is associated with? Or do I get a public account unassociated with the org?

[jgravois]

If I don't have an an AGOL account and I hit one of these sign in links and autoAccountCreateForSocial is true do I automatically get an account for the org that the client id is associated with? Or do I get a public account unassociated with the org?

if the default portal is passed, you'll still get a public account, but you won't see the dialog below prior to choosing your username.

if a custom portal is passed and the associated organization supports social login and also has a top-secret organization property set that allows the creation of new accounts without administrator approval, then you'll get an account in that org, regardless of the client id supplied.

[patrickarlt]

@jgravois ok so are these all the possible scenarios?

1. Default portal (https://www.arcgis.com/sharing/rest) and autoAccountCreateForSocial=true you get a public account that is automatically created and you won't see the dialog. I'm assuming you then see a screen where you put in your username and password.
2. Default portal (https://www.arcgis.com/sharing/rest) and autoAccountCreateForSocial=false same as option 1 but you see an extra dialog first.
3. Non-Default portal (https://myorg.maps.arcgis.com/sharing/rest) and autoAccountCreateForSocial=true AND secret org property set the user automatically gets an account with the org they don't see a dialog box I'm assuming you then see a screen where you put in your username and password.
4. Non-Default portal (https://myorg.maps.arcgis.com/sharing/rest) and autoAccountCreateForSocial=true AND NO secret org property set ???

[tomwayson]

I'm assuming you then see a screen where you put in your username and password

if by that you mean from the provider (i.e. a Google or Facebook password entry screen), then yes, unless you are already logged in to that provider, then you'll see the "ArcGIS wants to use your account blah, blah, blah".

Also, you do still have to select an ArcGIS username, even w/ autoAccountCreateForSocial: true. I know in the case of Google for a non-default portal there was a screen where I was prompted to enter a user name, and the default value that was filled was based on my Google account name. So if your gmail address is myname@gmail.com, it will assume you want to use to myname7 for your ArcGIS account (assuming myname1 - myname6 are already taken).

[tomwayson]

So where does this leave us w/ #240?

I don't know what happens in scenario 4 above, but it seems like by defaulting autoAccountCreateForSocial to true we could cause problems for orgs that don't have the super secret setting, so I'd rather expose that as a property so that they can opt into making that mistake themselves and then we're not accountable.

[jgravois]

4. Non-Default portal (https://myorg.maps.arcgis.com/sharing/rest) and autoAccountCreateForSocial=true AND NO secret org property set ???

true | false, auth blows up immediately when the org requires that new accounts are approved.

http://localhost:8080/authenticate.html?clientID=ePF8QFbgoWIkedxD#error=invalid_request&error_description=Joining this organization is supported by invitation only, you need to receive an invitation from the administrator.&messageCode=OAUTH_0024

because of this it seems appropriate for us to just hardcode true, at least for now.