I’m trying to integrate the Zumrails API in my Bubble app. Their documentation says they use Bearer Token Auth to authenticate requests. The auth endpoint returns a “Token” field that must be used with future API calls. I’m not sure how to proceed with this - which type of auth method to use in Bubble API connector, how to supply the right data so that the calls work, etc.
Here’s a request to the Auth endpoint (using auth type as “None/self-handled”) that works but I don’t know how to use the Token it returns in future calls.
Here’s another call I tried using auth type as OAuth2 Custom Token that doesn’t work since I don’t know how and where to supply the Token field that’s returned with the response to the authentication endpoint:
step 1. using API Connect tool make a call ( initialize ) to the auth endpoint. On success the response , or value of the token can be used until it terminates ( often a year ) .
#2 with the Workflow tool , link together actions making the call above, getting the response AND creating a new Type ( Token.token ) and run this using preview
#3 now you have in data tool what you will need to configure any subsequent workflows making API calls in which an authorization header is required . To config the authorization header use the following
key = “authorization”
value =" Bearer tokenValue" ← 1 space between Bearer and the copied token value
I had thought of doing it the way you suggested - storing the token in database, creating a recurring backend workflow to fetch a new token every hour, and using it for future API calls.
But I was wondering if there’s a simpler, more built-in way to handle this scenario. Bearer token auth is a common way of API authentication, and I thought there must be a setting in the API connector to configure this without having to do it via going down the route of storing token in database and refreshing it every hour.
Bubble API docs suggest they do have a way of handling these cases, I just need help with how I should supply the token field there:
If you’re using one of the OAuth2 flows, Bubble should automatically add the token you receive from the “authorize” endpoint to any future API calls as a Bearer token in the HTTP header. That is to say, you don’t need to add it. Bubble handles it.
If instead you decide to implement a self-handled approach, you’ll need to add a shared header called “authorization” and fetch your bearer token as suggested earlier.
It says “Unsupported media type” so I think the authentication went through but the issue is with the actual API call itself sending a bad payload, or maybe not? I’m not sure.
Here’s the API request that results in the above error:
You cannot use the User Password oAuth2 token process. This API doesn’t follow oAuth2 guideline. You need to create your own API Call.
Your first screenshot is ok. You need to manually call the authorizae endpoint and after use the token in header of each call with an Authorization: Bearer yourtoken header
That response object isn’t going to be picked up by Bubble automatically. You’re probably going to have to implement this manually by designing an API Connector call to fetch the token, identifying the token in the response object, and then passing the token as a parameter in the header of your other API calls. There’s at least one forum entry explaining how to do this.
Yeah, so that seems to be the only way I can get this working, like what @rowntreerob suggested. I was trying to avoid going that route since given how many configurations the API connector offers I was thinking there would be a more “built-in” way to do this.
Also, is this the forum entry you’re referring to?
That’s one of them (and it is a very good one.) There’s another I saw recently that focuses on the core of what I think you’re going to have to do - create an API Connector call to fetch that token and then create a backend workflow to invoke that connector call on whatever schedule you need to refresh it.
its more of a brute force force approach than built-in way. Brute force has potential to being the place that you iterate – to improve the built-in nature of your implementation.
The JWT spec when combine with bubble’s widely adaptable toolset almost certainly allows for better implements… in theory like below
default bubble app has stored app-level token allowing for one year of calls on the api with a scope == bubble.app.${abc} for read access to endpoint==3rdParty.endpoint
call this using api connector that was involved in connector.init() type call at any time up to a year ago
error handler on above catches err=token expired which will occur after a year
2.a fallback will RENEW token with same priviledge/scope as above to cover you for year 2
2.b call the auth endpoint ( not the normal api use endpoint ) of the api , parsing the response.token.value and storing that … either store in a client side cookie OR store in bubble db under the User ( logged in user )
2.c for the next year ( until token.exp ) just apply the cookies token value ( the renewed token ) back into the default scenario from #1 above
Discussion - normal auth process for mobile apps works along the above guidelines & implement steps where UX for auth involves a ONE_TIME step of auth that occurs when you install the app… and then user is never bothered by dialog for auth for up to a year when they may once again encounter the dialog over getting renewal on permissions.
that is user level example not example of an entire app being granted permissions on a 3rd party api
built in approach using plugin - renew the token value before expiration
Bubble provides tools / plugin that should ( in theory ) permit scheduled Token renewal on the client ie using a 1 year expiration and renewing the token on 11 month interval with scheduled WF. Token endpoint discussed above would not even be necessary because the bubble plugin permits payload/subject/audience config such that a verifiable token can be generated as needed using the plugin without leaving the client.
The server side endpoint for generating a token is shown below but using the client side shell script at the bottom, a passable token value can be reverse engineered ( and was in bash script ) and that bash gen’d token validated on the server. This demonstrates that with proper docs from the API , in theory, using the bubbles JWT plugins, you can gen your own token using it as required Bearer authorization in standard API auth using tokens.
