Question: Any recommendation on Social Sign In support

[fkwfung]

Hi @ottokruse,

Is there any support from the current client SDK to build social sign in (e.g. Google sign in)?

Comparing to Amplify Auth for client SDK, they have built-in support on using federated sign in to support Social logins or other OAuth endpoints (and you can customize based on Amplify Authentication documentation.

Thank you very much!

Frankie

[ottokruse]

Hi @fkwfung
In this case I'd recommend to use both this lib and Amplify, and init federated sign in with the Amplify method.
(You could then see this Passwordless lib as a helper to Amplify, complementing Amplify)

You've probably seen this already: Usage with AWS Amplify

You're not the first user to ask by the way, see discussion in #76 Initiating Oauth2 is pretty straightforward (just a browser redirect) and handling the redirect back from Cognito isn't hard either, so we were tempted to add it to this lib too (so as to be a one stop shop for Auth if it can), but it has little priority.

[fkwfung]

Thank you @ottokruse for the info.

Currently I'm using a combination of Amplify Auth and the Passwordless Auth client too. #76 could be better approach per your suggestion.

[ottokruse]

Currently I'm using a combination of Amplify Auth and the Passwordless Auth client too.

How is the dev experience for that? Any annoyances you run into?

[fkwfung]

Yeah, there were 3 main issues (I'm using React as web application):

1. Auth state checking - On each page refresh or Google sign in redirect, I will need to build a controller to determine which way the user is authenticated in order to retrieve id_token / access_token for API call from either Passwordless React hook or Amplify Auth functions. (I used a custom Lambda authorizer of which the frontend to pass the id_token as bearer to validate from the Cognito)
2. Concurrent sign in if federated identity not properly signing out - In some scenarios, if a user requests a Magic Link, and at the same time the user signs in via Google, after signing in, he then clicks back on the Magic Link from email. It will have both ways signed in. Understanding this is Application logic to handle various odd cases, but separating into two ways of authentication will increase the complexity of the controller to handle in scenarios like this.
3. Using "out-of-the-box" Amplify Analytics on Kinesis - The setup of the React application was originally overriding Auth config at runtime in React without defining at Amplify Backend. However, this is not possible if Analytics is applied. As Amplify forces to apply Auth (a Cognito must be defined in backend either new or re-use existing) for both authenticated and guest (unauthenticated) event tracking via Kinesis, we need to define a dummy Cognito, and manually assigning PutRecord permission on the original Passwordless Identity Pool.

Now I will see more value adding OAuth support on the Passwordless stack 👍
Thanks!

[ottokruse]

Oof sounds like some rabbit holes 😓 Glad though you were able to get there in the end.

If you can share code snippets of your work arounds that'd be great for better understanding.