Hey @stevenrichardlevy. I stopped using the Login w/social concept altogether, and handle the Oauth2 token dances manually, and I am very happy with the solution. Before starting you go the the vendor in question, login and create an application to get your app id, secret, etc. Each vendor implements their own flavor of the dance, but the basic flow is this:
–Using whatever trigger you’d like, direct the user to the vendor for authentication. This is where the user sees the allow this app type of screen.
–When the user approves, they will be redirected back to a url in bubble. I chose to have a page in bubble, with our basic header and an animated spinner, but no other content. The user gets this page and for a couple seconds, sees that something is being processed. What the page is doing in the background, is extracting information that was sent back from the vendor–usually this is a query parameter named "code’. You take that code and make a post back to the vendor in order to get an access token. Store that access token in your db, and redirect the user to whatever bubble page makes sense.
–You now have an access token that is added to every api call by adding a Header named “Authorization” and its value is "Bearer " plus the access token. These calls are setup in the API connector with formats specific to the vendor.
Anyhow, that’s the routine, and after you figure out the first one, you’ll be able to replicate with ease. It is completely bifurcated from bubble user credential login, so you have full control and can act on the users behalf as designed.
–Ken