My Microsoft Outlook integration, which uses Bubble’s OAuth2 User-Agent Flow using the API Connector, is failing after about one hour because the Access Token expires. Although I correctly included the offline_access scope, Bubble’s native OAuth process stores the resulting Refresh Token in a hidden cache that I cannot access from my database. I need a way to create the refresh token endpoint for a seamless user experience, instead of having to signin every hour.
How to do it? Should I change Bubble’s OAuth2 User-Agent Flow?
Do you mean to change it to None or self-handled? Is there any way to create a refresh token endpoint using OAuth2 User-Agent Flow? Or by allowing “Requesting an access token uses Basic Auth”
Keep in mind @mariam.alaa that Bubble doesn’t refresh the access token for API connector itself but will do it for your user. If you set your API correctly with user-agent flow, you have nothing to do, Bubble will refresh token when it’s needed.
You don’t need to. Bubble will handle it for you like I said. You don’t need to add any other call to fetch a new access token using refresh token.
If you need to modify or add more call in API connector, you will just need to use the login with social network flow in debug mode to fetch a new access_token for the API connector. But for your user, you have nothing to do.
However, some API will request you to use “offline” to get refresh_token. For MS Graph, this is set in the scope with &scope=offline_access (so in Bubble, just add offline_access to the list of scopes).
Thanks @Jici that helpful. It’s important for @mariam.alaa to note that they might not be able to access the refresh tokens and access token using the OAuth agent flow which might be a limitation depending on the use case.
Another limitation of this approach is that bubble creates a user in the database corresponding to the Oauth call which may be unwanted by the developer.
Lastly it’s harder to debug as Bubble is handling the calls internally so one can’t easily debug if there’s any error or possible timeout.
It’s for this reason I prefer the self-handled option.
This is not an issue because you need to link the access_token to a user for security.
What do you mean? The only part you cannot debug is the auth part. The rest of the API call can be debugged.
That is true that it could be a limitation but for specific case like using the auth from a user when you are logged in into another user. For example, you have an app that need to check a calender of user A when user B try to book something with user A. At this moment, you need to self-handled the process. However, when you don’t need something like that you should use user-agent because this is more secure. Also, there’s a workaround to access the user access_token using backend WF.
You should not prefer something. You should use what is best for the use case and keep in mind the security of token.
obviously the Oauth Agent Flow you are referencing falls short. In terms of security, that’s up to the developer and how they handle and store the token.
You also need to consider refresh tokens that expire after a while(especially in test mode, if not pushed to production), does the Oauth agent flow help handle the process of getting a new refresh token?
Ultimately a developer has to weigh their use case and choose their preferred method for approaching a particular problem while keeping in mind best practices and security.
Exactly what I said. But using the user-agent flow add another layer of security because there’s no way to expose access_token even if you didn’t set privacy rules correctly.
This can happen. But it’s pretty rare. But the correct way to handle this is to ask the user authorization again and this is mostly why some API will make refresh token expires.
Test mode is… a test mode and should be use for what is it! You should not try to go live with API that is not in production.
