Recommended approach for social login w/backend?

Expo SDK
1

Hi,

I’m working on integrating social login for FB og Google into my expo app. The app has a Node/express backend that saves the email + some user details and I am struggling to create a good auth flow.
What is the current recommend approach for achieving this?

Currently our web app uses Passport.js with the Facebook strategy
Is there any way to combine the two?

768×1024 60.5 KB

2

It’s been a few years since I did any social-auth flows so I might be off, but from what I recall, the normal auth flow for websites (don’t worry, I’ll explain why this is key for mobile soon) is;

  • User registers to your service (or links their existing account with their FB account) using the FB API (triggered by Passport if I recall correctly)
  • You return their auth token back to your server, and associate it with their (newly created or existing) account
  • When the user logs in to your service with FB, you look up the database for the auth token that’s passed back from FB, ensuring it’s not expired or requesting the FB api to issue a new token if it is expired

With Mobile, the flow can be similar - using webview. Alternatively, you can return the token to your app instead, and use secure storage to store it (NEVER use regular async-storage as you’re exposing it not only to other expo apps during dev, but to any other app during production usage).

When the user logs in with FB via the app, you trigger a call to the FB API (using the expo-provided FB library) with the token stored on the device, and then handle the same as above (i.e. check not expired, request new one if it is, etc).

3

Hi,

From what I gather from your response the web approach used by passport-facebook, even though it is possible, does not seem to be recommended.

With the token approach where you get the token sendt first back to the client app. How do you get the user info (email, profile, etc) over to the server? Do you forward the token from the client to the server and then make a new request for the info on the backend?

Would the Passport-Facebook-Token strategy outline the standard approach?

Regarding storing the token in a secure way. Here I use the SecureStore provided by Expo.

4

The information you request is setup in the application configuration on the FB developers site (you choose what permissions your app is requesting). You choose what information your application wants to access (e.g. similar to application permissions) and this information is presented to the end user when they auth, allowing them to toggle which information they wish to provide. Public profile is one that is always provided on successful auth (as it can’t be toggled off). Email used to be in here I think, but this has probably changed now.

In the Passport-facebook-token strategy docs, in the first code sample on the readme, it has a ‘profile’ argument in it’s callback. This is an object that contains the profile data returned by the FB graph API. It also returns accessToken and refreshToken parameters. You can store these in a database (or secure storage).

The caveat is that depending upon what you’re doing besides login (if anything), you might hit a problem due to the whitelisted URL setup that FB use on applications. I haven’t worked with FB auth from a mobile context (especially without having my own server sat somewhere in between to handle auth).

As I said, it’s been a while since I worked with Passport (and with the FB API) so some of the above might be a bit out of date or no longer recommended.

5

@chronsyn appreciate the clarification on the FB backend.

Had a deeper look at it today and it turned out that I had a misconception about the universality of the FB token fetched from Expo.Facebook. Securely sending the FB token over to the backend, handling data fetching via passport-facebook-token and sending our own token back works great.

6

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.