OAuth2 User-Agent Flow token extraction

Hi everyone !

I am using Spotify API, using their authorization code flow.

  1. For specific reasons, I need to reuse the Spotify Authentification Token elsewhere.

The API using Bubble API Connector (with OAuth2 User-Agent Flow) works fine, but I can’t access or use the spotify authorization code or tokens.
Do you know any solution ?

Otherwise, I need to reproduce the Spotify authentication workflow without OAuth2 User-Agent Flow but there is a lot of steps, and it’s not very smooth.

  1. Spotify API uses a refresh token mechanism every hour, is it natively handle by the OAuth2 User-Agent Flow ?

Thank you very much!!

1 Like

Up someone?

If it can helps someone, what I finally did is reproduce the whole Spotify authentification using workflows and a “Spotify auth page” on Bubble to redirect users when page load.
Then I could store the user Token & Refresh Token into my database.
I refresh the token every time a user loads my app.

It takes more time to configure than using the Bubble OAuth2 User-Agent Flow, but it works.

3 Likes

hey @pierreantoine, mind sharing the exact workflow? :slight_smile:

If you’re going to store a long term (non-expiring) access token in the database, I would recommend that you encrypt the token at rest and decrypt it only when you want use it, e.g when making an API call. Don’t keep the encryption key in the database. Even though the bubble database is already encrypted at rest, if it is hacked or you haven’t properly configured privacy roles, your users’ tokens could be leaked. By encrypting it, it means the even if this happens, the tokens can’t be used.

Here is a demo : https://bubble.io/page?type=page&name=index&id=demo-spotify&tab=tabs-1

You have to create 2 API connections using the API Connector.

On the connection button workflow, the redirect uri should focus a dedicated page on your app (spotify auth page for me).

Then another workflow is executed when the auth page load.

Remember that the Spotify acess token will expire in few hours, so you need to refresh it when it has been expired and using the user refresh token (see the custom event).

If you find optimizations or better solution it will be great to share it !

3 Likes

Your are right, even if the access token expires frequently, we should encrypt the refresh token that is more persistent. But do you have tips on how to do so?

Are you trying to build this work-around because the Spotify API doesn’t have the option to “add access_type=offline”?

I’m asking because I am I’m struggling trying to get Zoho CRM API v2 to work server-side.

1 Like

What is the purpose of this option ?
I’m using this workaround because I need to reuse the access token on a iOT device.

I believe it is to keep refreshing the token in the background. If you’re using an IoT device, you’re probably trying to do that, too, correct?

I’m learning about it here: google api - What does "offline" access in OAuth mean? - Stack Overflow

Yes if it does what you say, that would also be interested for me.
But I didn’t know so I’m refreshing the token by myself…

Hi Rico,

did you finaly get the Zoho CRM API V2 working ? I’ve been struggling for two days now, any help would be much appreciated :slight_smile:

No. Another colleague - with deeper developer chops - also tried and gave up.

Our solution was to use Functions in Zoho and expose those via the REST API function.

Ok thanks, sounds like a decent workaround.
The zoho functions aren’t as powerfull as the coql queries (AND logic only, no OR) but better than nothing.

Cheers