Free Plugin - OAuth login (SSO) with 7 identity providers

This one was huge in the making - SSO Login (Multiple Providers) plugin!

We just released a plugin that allows you to add Single Sign-on (SSO) login capabilities with multiple providers without the effort of setting up an OAuth Token Authorization and Refresh Flow.

Plugin URL | Documentation

The plugin offers identity login across 7 different providers.

  • Google
  • LinkedIn
  • Twitter
  • Facebook
  • GitHub
  • Azure Active Directory
  • Microsoft

UI/Visual Element

Additional Functionality

Sets or clears the following states once logged in

  • SSO Profile Email
  • SSO Profile Id
  • SSO Profile Name
  • SSO Profile First Name
  • SSO Profile Last Name
  • SSO Profile Set

Let us know if you have any questions or feedback.

Pathfix Team

No-code Plugins | Documentation



Plugin updated with an additional SSO Profile element. The element captures the state of authentication and offers profile info (Name, Email, Provider) that you can save to your Bubble User DB.

Workflow Setup

Detailed documentation link (contains video walkthrough):

1 Like

I look forward to testing this one out!

1 Like

@Pathfix - please please can you change the flashy icon :grimacing: :rofl:

It is driving me loopy, thanks. Cool though. But please :slight_smile:


we hear you, will certainly look into it :slight_smile:

1 Like


When using these types of signin, am i still able to use “current user” data? My understanding would be no because the bubble system doesn’t know you’re logged in, instead that login provider knows you’re logged in.

i use the ‘current user’ a lot. I’m wondering how these 2 tie together?

Hey @jared.gibb when you use the SSO plugin, it signs your users in and gives you the users public profile information (name, email, provider and picture) that you can access in the element state.

The right way to go about this would be to ‘Sign the user up’ with the information available in the SSO profiles state and then ‘Log the user in’ as the current user.

Once this is done, you continue working with the Current User in Bubble as you have effectively transferred the SSO profile to the Current User in Bubble.

However, its important to include this in your signup workflows early on.



I know this is coming back in the element, but if I wanted o do a passthru call to …

How would I go about it? I get 401s when I try. Have added the scope in GConsole.

Hey @NigelG I hear this is sorted :slight_smile:

Feel free to reach out if you need any assistance (email or live chat support)


1 Like

hey @Pathfix , i added this element to my screen today. signed upfor the API key thru google for the authentication. added that to the plugin page.

when i preview the screen, i see nothing.

any ideas there? i see no errors/logs in the console to indicate an issue

Hey @jared.gibb The Google Keys would need to be added in Pathfix (not directly in the plugin). I can walk you through this on live chat here (

Edit: Here is the detailed documentation link to the plugin:


Hi - how would the implementation of this work for existing users? If I have a user that has already created an account on Bubble and then tries to login with SSO is there a way of detecting this via a workflow using this plugin and enabling SSO on their account?

Hey @messly are you looking to offer dual login or are you looking to replace the signup method for the user?

Just a bit of a Gotcha to warn people about (it is an edge case (obviously!) but confusing when it happens)…

If you sign up to Pathfix with then that is the account that you need to pass when “initialising” in the API.

This is not always that helpful, as you may have set up your Google Cloud Platform project in a different way. Or need to authorise with a different email address.

My Edge Case - For “sensitive” scopes (i.e. just reading a calendar), Google now requires you to get your app validated prior to use, which is a pain when testing. You can either click through the dire warning on the browser each time, or set it up so that you limit the access to emails on the owned domain you are using at the time. The latter is simpler for testing.

So if you set up the app to allow access from only * then but Pathfix is registered to then it will constantly give you an unauthorised error when doing a Passthru call. Something like “The Host or Origin does not have priveleges to complete the request.” - Yeah, complete with spelling mistake :slight_smile:

Even if you sign up using the account to your app, it will fail on Initialise.

What you need to do is navigate to …

With the email address in your API call and your Pathfix Public key, and this will authorise it to the Passthru.

Am sure there are other use cases, but it is confusing when you are always getting errors.

1 Like

A second thing to remember is that when doing a GET via the passthru then the “payload” is not all that useful.

For example, Google uses QueryStrings on the List Calender Events endpoint.

Don’t put them in the payload. Nothing will happen.

This is actually a lot fiddlier than it should be :slight_smile:

The good news - it all works really nicely (fiddly bits included) and allows you to concentrate on navigating Google’s hideous APIs without worrying about the authentication.

@Pathfix for Twitter, SSO Profile ID means the handle?

@sharma.himanshu0608 here’s the profile info received from the provider:

There is no profile ID made available elsewhere.

I think @NigelG is referring to SSOProfile A in the below screenshot as the Element:


@Pathfix I meant the Twitter username. That is not possible to retrieve with the plugin I guess?

Hey @Pathfix team,

Could you please provide me with more information on the following :

  • Is the Instagram login covered by your plugin (paid version?)
  • I played with your demo app. An authorization is given to retrieve, among other info, the name and the profile picture. Is the user profile picture retrievable after login?

Many thanks!

@sharma.himanshu0608 I believe we get the information in the Public Profile and we could expose an additional property, but it would be non-standard across all the providers (since only the social networks may offer this).

So, we think it should be possible to retrieve this information and made available through the SSO profile for…

  • Twitter
  • LinkedIn
  • Facebook
  • Instagram (once we release it)