Running API workflow for user (oAuth2 User-Agent flow) while not logged in?

Is it possible to run API workflow for a user while they are not logged in or on the application? For example, I want to get new emails for a user even if they are not currently using the app. I think I made the mistake of using “Login via Social” & “Current user” in parts of my API workflows, thinking that it would always reference the user, but after reading a couple of posts and thinking about it, I think that certain parts of the workflow are not going to work.

For example, I have a webhook that sends a notification to my app when the user’s email has been updated. Then I have to make a call (currently using oAuth2 User-Agent flow) to that email system to get the updates. It seems that since the API workflow is doing the call it doesn’t know what user to make the call as.

1 Like

Right, the API doesn’t see Current User, so you need to send the User to the API endpoint or otherwise search for the User.

If using something like “Get data from API” you don’t specify the user though… it’s somehow implied based the API authentication that’s been setup for the call.

Ya, I have no experience with oAuth2. May want to put that in the subject line above.

You can definitely trigger calls on behalf of a user not logged in, but I only know how to do it by storing the tokens myself instead of using the user-agent flow. If you have the access token, you can perform any calls, whenever you’d like. Once you get the hang of managing the oauth dance to get things established, it is easily repeated with slight modifications for other api’s.

@Bubble is this a limitation or am I setting something up wrong?

Is there a way to define the token to use, or the related user to use, when calling APIs in workflows while the user is not logged in or physically triggering the workflow event?

So this is what you did? How do you manage token refresh?

4 Likes

Depends on the requirements of the api.

For example, Google: When you initially connect an account, you get an access token and a refresh token. The access token is granted along with a duration, so you will know when it expires. If current date/time is later than expiration, you take the fresh token and get a new access token. Before running the actual call, I send it through a common check for this and then execute the actual call. Refreshing the token does not require the user to be present. If you want to add additional scopes, the user needs to be present and authorized the changes.

However for Eventbrite, the access token does not expire, so it is refreshed only if there is an error generated (user changes password at Eventbrite, etc.)

For Plaid, they trigger a webhook if the user’s account goes into an error state, so if that happens, the app gets a notification and we send off an email and set a flag so that when the user logs in we can guide them to reconnect their account…otherwise, the token does not expire.

1 Like

Thanks Ken! Looks like I’ve got some reading and rebuilding to do. :frowning:

1 Like

@mebeingken did your access token get returned as a query parameter or JSON?

I’m trying to figure out how to “grab” the data that’s returned to the redirect URL once I’ve made a POST with the auth code.

Hi Keith,

Well, on the one hand, it sounds like you are actually trying to retrieve the code (not the access token) because that is what is sent back to the redirect url. That is done like this:

But you are also saying the access token being returned, which is the next step. In that case, I think json will work for most. For example, here’s the one I use for Google, which takes the aforementioned code and exchanges it for the access token:

So to summarize, the initial oauth dance is usually:

Send user to url at remote site
User grants permission
Remote site sends “code” to redirect url
Redirect url “catches” the code and retrieves access token
Access token then stored and ready for use

6 Likes

Ah ok! Create an API, much easier than trying to use @mishav javascript to bubble. :slight_smile:

Hi Keith. Appreciate this is a bit of an old thread. I have been trying to take on the manual authorisation flow for MS Graph and can’t seem to get the authorisation code flow to allow a user to register.

I’ve created a MS developer office 365 account with multiple users within the organisation so I can test out various flows.

What is odd was that using your plugin I could register users, and collect their profile and details, I just couldn’t send email. This is the only thing I am trying to allow.

I then read about your switch to handling the authentication manually and have been trying that - so far totally unsuccessfully. It seems that now I am handing it via the authorise and token ms endpoints from the authorisation flow, I am getting an error that an admin in the organisation needs to approve my app.

Previously with your plugin somehow it was able to make calls to the profile and other things with just the user approval so I am sure that it must be possible to not be getting these errors.

Would you be able to explain in summary how you’re handling the dance between the app and microsoft. Even manually using postman I am not able to get it to convert my granted code to an access token at the moment…

If all the users for my app will need to get administrator consent to use it at all, it will be significantly less useful and I may just not be able to build it at all.

Given that I was able to login and grant access to all the permissions your plugin was requesting with the test user I was using, I’m thinking I should be able to somehow use your plugin / ms graph to send an email without having to get admin consent but I couldn’t figure out how to use the plugin to do that despite it registering the user correctly from what I could tell.

If you are able to point me in the right direction with either of those possible solutions it would be really appreciated!

Ben.

So after reading a bit more from the graph developer documentation on github (not the official ms documentation which annoyingly doesn’t mention this from what I could tell) I found a solution to my issue which actually was annoyingly simple.

It appears that changing the scope parameter and adding /.default to the end of the Ms graph token API url fixes the issue. I replaced all the ms graph scopes I was using previously with this one entry. Doing that allowed me to get the endpoint to trigger generation of the tokens I needed when I sent the code that was returned from the microsoft identity platform in the URL.

In my case if I declared the scopes in a space separated list - as it says to do the in the ms docs!!! - I was not getting the tokens back I was getting an odd error about the user needing to approve. Replacing the manually typed scopes with the below caused it to work and automatically ask for all the permissions which I’d requested in the permissions section of the ms Azure portal without me having to define them all.

scope=https%3A%2F%2Fgraph.microsoft.com/.default offline_access openid

None of this is intuitive at all and I am now struggling with how I am supposed to login a user using the ms authentication API. It seems that there is a different process to generate an access token for the graph API, than there is to verify the user should be logged in to the app. If you try to re-run the initial auth process later to verify logins with microsoft, the API throws an error about the code having already been redeemed.

In any event, I managed to get initial authentication working and delegated permissions. I’ve been able to manually handle the API calls for MS graph auth as well as using the acquired details to register a user and pull / send data to the graph API as the user with the tokens retrieved. With all that done, with a bit more exploring I should be able to figure out the next part to allow easy login… Worst case I will just stick with basic bubble login but it seems crazy that I’d need to do that now I can seemingly use the ms API’s.

Thanks all for documenting your steps. It was super helpful and probably caused me to avoid giving up totally.

Hi all,

Not sure how it works for GitHub but for Google just check the offline button. The process is maybe similar for github

Access tokens periodically expire and become invalid credentials for a related API request. You can refresh an access token without prompting the user for permission (including when the user is not present) if you requested offline access to the scopes associated with the token.