#1601 Add support for social login

[taurgis]

Description

Adding IDP login to the PWA Kit has gotten quite a bit of questions lately on Slack, and they say an example said more than a thousand words? Wait.... that's not the saying

Types of Changes

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Documentation update
• Breaking change (could cause existing functionality to not work as expected)
• Other changes (non-breaking changes that does not fit any of the above)

Screen.Recording.2023-12-06.at.14.38.53.mov

Configuration required in SLAS:

Additional redirect URLs required:

http://localhost:3000/idp-callback|https://*.mobify-storefront.com/callback|https://*.mobify-storefront.com/idp-callback

IDP Configuration Required

[taurgis]

This is a workaround since this isn't part of the package. Unsure how you would like to see this handled. The reason the authentication is completely separated is because these items are part of the isomorphic SDK.

[bfeister]

Small question on this: it works only because this file is in js rather than ts and thus doesn't respect the private keyword since it's a compile time annotation, right?

[taurgis]

Correct. This could be changed if I add this function to the Auth.js

async loginIDPUser(body: { code: string; usid: string, redirectURI: string }) {
           return await this.queueRequest(
            () => {
                const tokenBody = {
                    code: body.code,
                    usid: body.usid,
                    grant_type: 'authorization_code_pkce',
                    redirect_uri: body.redirectURI,
                    code_verifier: localStorage.getItem('codeVerifier') || '',
                    client_id: this.client.clientConfig.parameters.clientId,
                    channel_id: this.client.clientConfig.parameters.siteId
                };

                return this.client.getAccessToken({ body: tokenBody });
            },
            false
        )
    }

[bfeister]

First off, 👏 we really appreciate contributions like this for key features!

Second, 😂 it's true. Code is worth more than 1,000 words or a picture! (sometimes)

@taurgis I'm trying to think through how this interfaces with plugin_slas. I could be wrong, but I feel like plugin_slas is where we most frequently hear complaints about lack of IDP / federated login. In plugin_slas we hook into Account-SubmitRegistration controller in SFRA. Mentioned in [this REDESIGN.md doc](https://github.com/SalesforceCommerceCloud/plugin_slas/blob/develop/REDESIGN.md - search for Account-SubmitRegistration). I wonder if this is something to be concerned about... thoughts @vcua-mobify @shethj ?

In this PR, it feels like we're sidestepping "real registration" by going directly from PWA Kit to the IDP provider. Correct me if I'm wrong, but we don't actually go through a real user registration on the SLAS side in this, do we?

And if the answer there is "no, it follows the guest slas auth flow" we end up in a situation where "real authenticated users" that come in via IDP kind of unintentionally mess around with the data because everyone appears to be a guest.

Perhaps this is ok, but also, perhaps it's not. Will require some more thought and discussion.

[taurgis]

First off, 👏 we really appreciate contributions like this for key features!

Second, 😂 it's true. Code is worth more than 1,000 words or a picture! (sometimes)

@taurgis I'm trying to think through how this interfaces with plugin_slas. I could be wrong, but I feel like plugin_slas is where we most frequently hear complaints about lack of IDP / federated login. In plugin_slas we hook into Account-SubmitRegistration controller in SFRA. Mentioned in [this REDESIGN.md doc](https://github.com/SalesforceCommerceCloud/plugin_slas/blob/develop/REDESIGN.md - search for Account-SubmitRegistration). I wonder if this is something to be concerned about... thoughts @vcua-mobify @shethj ?

In this PR, it feels like we're sidestepping "real registration" by going directly from PWA Kit to the IDP provider. Correct me if I'm wrong, but we don't actually go through a real user registration on the SLAS side in this, do we?

And if the answer there is "no, it follows the guest slas auth flow" we end up in a situation where "real authenticated users" that come in via IDP kind of unintentionally mess around with the data because everyone appears to be a guest.

Perhaps this is ok, but also, perhaps it's not. Will require some more thought and discussion.

Also, this PR does not need to be merged in my eyes, but could also serve as an example to get your own internal implementation going. There are a few dependencies that will indeed warrant discussion.

[vcua-mobify]

First, I want to echo @bfeister and say thanks for this @taurgis !

@bfeister, as you say, plugin_slas also does not have support for federated login. If we were to add support there, at a high level it would follow the same steps done here and as outlined in the SLAS documentation.

In this PR, it is a separate flow from the out of the box guest or registered login flows. It looks similar to the guest flow in that there is a call to SLAS /authorize. Good question on whether everyone will appear afterward as a guest. I would think because in the /authorize call hint is set to idp rather than guest, users will be appropriately marked as registered within SLAS but it is something to verify.

We'll also have to think about the new user registration signup case but I think that can be handled by the idp so from our perspective it might just go through the same flow as shown in this PR

[unnii]

Hi @taurgis
During the OAuth flow with Facebook, we only receive a code parameter in the response without a usid. Is there a recommended approach or additional step to retrieve or generate a usid after receiving the authorization code from Facebook?